DE112011100258T5

DE112011100258T5 - Durchführen von aggressiven Codeoptimierungen mit einer Fähigkeit zum Annulieren derdurch die aggressiven Optimierungen vorgenommenen Änderungen

Info

Publication number: DE112011100258T5
Application number: DE112011100258T
Authority: DE
Inventors: Michael K. Gschwind
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2010-03-01
Filing date: 2011-02-25
Publication date: 2013-04-25
Also published as: CN102782644A; JP5643345B2; GB2491768A; US20110214016A1; WO2011109230A1; US8495607B2; GB201217266D0; GB2491768B; JP2013521572A

Abstract

Es werden Mechanismen zum aggressiven Optimieren eines Computercodes (415) bereitgestellt. Mittels dieser Mechanismen wird ein ausführbarer Code (415) empfangen, der einen Teil eines Codes aufweist, für den eine aggressiv kompilierte Codeversion (420) und eine konservativ kompilierte Codeversion (430) des Teils des Codes bereitgestellt werden. Die aggressiv kompilierte Codeversion (420) des Teils des Codes wird in einem Prozessor (206) des Datenverarbeitungssystems (450) ausgeführt (610). Es wird eine Ermittlung (620) durchgeführt, ob während der Ausführung der aggressiv kompilierten Codeversion (420) eine Ausnahmebedingung auftritt. Änderungen an einem Zustand des Teils des Codes werden als Reaktion auf eine Ermittlung (620), dass eine Ausnahmebedingung auftritt, annulliert (630). Die konservativ kompilierte Codeversion (430) wird in dem Prozessor (206) des Datenverarbeitungssystems (450) als Reaktion auf das Annullieren (630) der Änderungen an dem Zustand des Teils des Codes ausgeführt.

Description

Diese Erfindung wurde mit Unterstützung durch die Regierung der Vereinigten Staaten von Amerika erstellt und durch das Energieministerium (Vertrag Nr. 8554331) gefördert. DIE REGIERUNG DER VEREINIGTEN STAATEN VON AMERIKA HÄLT BESTIMMTE RECHTE AN DIESER ERFINDUNG.
TECHNISCHES GEBIET DER ERFINDUNG
Die vorliegende Patentanmeldung betrifft im Allgemeinen eine verbesserte Vorrichtung und ein verbessertes Verfahren zur Datenverarbeitung und insbesondere Mechanismen zur Durchführung aggressiver Codeoptimierungen mit einer Fähigkeit zum Annullieren der durch die aggressiven Optimierungen vorgenommenen Änderungen.
STAND DER TECHNIK
Üblicherweise wird für ein Programm, das auf einem Rechnersystem ausgeführt werden soll, der Quellcode für das Programm kompiliert und so verknüpft, dass ein ausführbarer Code erzeugt wird. Als Bestandteil des Kompilierungsprozesses führt ein Compiler üblicherweise eine oder mehrere Optimierungen des Quellcodes durch, um eine effizientere Programmausführung zu ermöglichen. Der Compiler kann zwar viele Möglichkeiten ausfindig machen, den Quellcode umzuwandeln und dadurch seine Ausführung zu optimieren, ist normalerweise jedoch durch die Semantik des kompilierten Quellcodes bezüglich der Optimierungen, die er durchführen kann oder wo solche Optimierungen angewendet werden können, beschränkt.
In Grenzfällen, die nur selten oder praktisch nie eintreten, stößt die Codeoptimierung zum Beispiel auf Grenzen, da hier stets mit Randbedingungen zu rechnen ist. Das heißt, wenn eine bestimmte Quellcode-Anweisung durch eine bestimmte Compileroptimierung umgewandelt wird, kann dies zu einer Randbedingung führen, obwohl dies während der Ausführung praktisch gar nicht oder nur selten eintreten kann, sodass der Compiler die Optimierung nicht durchführen kann, die er normalerweise hätte durchführen können, wenn diese mögliche Randbedingung nicht vorgelegen hätte. Bei solchen Randbedingungen handelt es sich zum Beispiel um die Umwandlung von Quellcode in einen optimierten Code, der sich über eine Grenze einer Speicherseite erstreckt und auf diese Seite nicht zugegriffen werden kann, d. h. die Speicherseite ist für Lese- oder Schreiboperationen oder für beide gesperrt, oder die Seite wurde „ausgelagert”, d. h. auf einem externen Speichermedium gespeichert und aus dem Arbeitsspeicher und der Seitentabelle gelöscht. Zum Beispiel besteht eine Compileroptimierung, die von einem solchen Grenzfall betroffen sein kann, in der Umwandlung eines skalaren Quellcodes in einen kompilierten Vektorcode. Der Compiler ist bestrebt, das Verhalten des Original-Quellcodes nach solchen Umwandlungen beizubehalten. Bei der Umwandlung eines skalaren Codes in einen Vektorcode kann es jedoch vorkommen, dass es bei dem skalaren Originalcode nicht zur Verletzung von Randbedingungen kommt, wenn der Skalarcode sequenziell ausgeführt wird, während es nach der Umwandlung in den Vektorcode, der parallel ausgeführt wird, zur Verletzung von Randbedingungen und somit bei dem umgewandelten Code bezüglich des vom Quellcode übernommenen ursprünglichen Verhaltens zur fehlerhaften Ausführung des umgewandelten Codes kommen kann. Wenn ein in einer Multithread-Umgebung auszuführender Code umgewandelt wird, kann der umgewandelte Code darüber hinaus eine Konkurrenzsituation zwischen Threads erzeugen, bei der zwei oder mehr Threads parallel auf denselben Datenbereich zugreifen, sodass durch das Schreiben der Daten durch einen Thread Fehler in die Ausführung des oder der anderen Threads eingeführt werden.
Wenn ein Compiler feststellt, dass es in dem umgewandelten Code zu einer Verletzung der Randbedingung kommen kann, führt der Compiler deshalb die Optimierung für diesen Codebereich für gewöhnlich nicht durch, um jede noch so unwahrscheinliche Möglichkeit auszuschließen, dass der umgewandelte Code anders als der Ausgangs-Quellcode ausgeführt werden kann. Somit ist der kompilierte Code nicht so gut wie möglich optimiert, da die Optimierungen in Bereichen nicht vorgenommen werden, wo möglicherweise eine Randbedingung verletzt werden oder ein Verhalten eintreten könnte, das nicht mit dem Original-Quellcode konsistent ist.
Alternativ kann ein Benutzer dieses Verhalten des Compilers manuell umgehen und den Compiler anweisen, diese Semantik zu ignorieren. Dadurch kann der Compiler die Umwandlungen dennoch vornehmen, jedoch kann dies zu einer fehlerhaften Ausführung des umgewandelten Codes führen. Darüber hinaus wissen Benutzer oft nicht, dass im Quellcode oder im umgewandelten Code eine bestimmte Semantik wichtig ist, und scheuen sich, das normale Verhalten des Compilers außer Kraft zu setzen.
OFFENBARUNG DER ERFINDUNG
Gemäß einem Ausführungsbeispiel wird ein Verfahren in einem Datenverarbeitungssystem zur aggressiven Optimierung eines Computercodes bereitgestellt. Das Verfahren umfasst das Ermitteln einer Optimierung, die auf einen Bereich eines Quellcodes angewendet werden soll, durch einen Compiler, der auf einem Prozessor in dem Datenverarbeitungssystem ausgeführt wird. Das Verfahren umfasst ferner das Ermitteln durch den Compiler, ob die auf den Bereich des Quellcodes anzuwendende Optimierung zu einem unsicheren optimierten Code und somit zu einer unsicheren Optimierung führt. Bei dem unsicheren optimierten Code handelt es sich um einen Code, der eine neue Quelle von Ausnahmen einführt, die durch den optimierten Code erzeugt wurden, oder Ergebnisse liefert, die von den Ergebnissen verschieden sind, die durch den Originalcode erhalten worden wären. Darüber hinaus umfasst das Verfahren als Reaktion auf die Ermittlung, dass es sich bei der Optimierung um eine unsichere Optimierung handelt, das Erzeugen durch den Compiler einer aggressiv kompilierten Codeversion des Bereichs des Quellcodes, auf den die unsichere Optimierung angewendet wird, und einer konservativ kompilierten Codeversion, bei der die unsichere Optimierung nicht angewendet wird. Außerdem umfasst das Verfahren das Speichern sowohl der aggressiv kompilierten Codeversion als auch der konservativ kompilierten Codeversion durch den Compiler in einer mit dem Datenverarbeitungssystem verbundenen Speichereinheit.
Gemäß einem anderen Ausführungsbeispiel wird ein Verfahren in einem Datenverarbeitungssystem zum Ausführen eines Teils eines Codes bereitgestellt. Das Verfahren umfasst das Empfangen eines ausführbaren Codes mit einem Teil eines Codes, für den eine aggressiv kompilierte Codeversion und eine konservativ kompilierte Codeversion in dem ausführbaren Code bereitgestellt werden. Ein Prozessor in dem Datenverarbeitungssystem führt die aggressiv kompilierte Codeversion aus und ermittelt, ob es während der Ausführung der aggressiv kompilierten Codeversion zu einer Ausnahmebedingung kommt. Das Verfahren umfasst ferner das Annullieren von Änderungen an einem Zustand des Teils des Codes, nachdem ermittelt wurde, dass eine Ausnahmebedingung auftritt. Darüber hinaus umfasst das Verfahren das Ausführen der konservativ kompilierten Codeversion in dem Prozessor des Datenverarbeitungssystems als Reaktion auf das Annullieren der Änderungen an einem Zustand des Teils des Codes.
Gemäß anderen Ausführungsbeispielen wird ein Computerprogrammprodukt bereitgestellt, das ein durch einen Computer nutzbares oder lesbares Medium umfasst, auf dem ein computerlesbares Programm gespeichert ist. Das computerlesbare Programm wird auf einer Recheneinheit ausgeführt und veranlasst die Recheneinheit zur Ausführung verschiedener Arbeitsschritte einzeln oder in Kombination, die oben unter Bezugnahme auf Ausführungsbeispiele des Verfahrens dargelegt sind.
Gemäß weiteren Ausführungsbeispielen wird ein System/eine Vorrichtung bereitgestellt. Das System/die Vorrichtung kann einen oder mehrere Prozessoren und einen Speicher umfassen, der mit dem einen oder den mehreren Prozessoren verbunden ist. Der Speicher kann Anweisungen aufweisen, die durch den einen oder die mehreren Prozessoren ausgeführt werden und den einen oder die mehreren Prozessoren zur Ausführung der verschiedenen Arbeitsschritte einzeln oder in Kombination veranlassen, die oben unter Bezugnahme auf Ausführungsbeispiele des Verfahrens dargelegt sind.
Diese sowie weitere Merkmale und Vorteile der vorliegenden Erfindung werden in der folgenden detaillierten Beschreibung beispielhafter Ausführungsformen der vorliegenden Erfindung beschrieben oder ergeben sich für den Fachmann offensichtlich daraus.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung sowie eine bevorzugte Ausführungsform sowie weitere ihrer Zielstellungen und Vorteile lassen sich am besten aus der folgenden Beschreibung von Ausführungsbeispielen in Verbindung mit den beiliegenden Zeichnungen verstehen, wobei:
1 ein beispielhaftes Blockdiagramm eines Datenverarbeitungssystems darstellt, in dem beispielhafte Mechanismen der Ausführungsbeispiele realisiert werden können;
2 ein beispielhaftes Blockdiagramm eines Prozessors eines Datenverarbeitungssystems darstellt, in dem Aspekte der Ausführungsbeispiele realisiert werden können;
3A die Sequenz eines Original-Quellcodes für einen Teil eines Codes veranschaulicht;
3B dieselbe Codesequenz nach der Optimierung durch den Compiler veranschaulicht, um den Teil des Codes zu vektorisieren, damit er durch einen Vektorprozessor effizienter ausgeführt werden kann;
3C ein beispielhaftes Blockdiagramm darstellt, das die Verletzung einer Randbedingung veranschaulicht, die durch die Vektorisierung des in 3A und 3B gezeigten Codes erzeugt wurde;
4 ein beispielhaftes Blockdiagramm der primären Funktionselemente gemäß einem Ausführungsbeispiel zeigt;
5 einen Ablaufplan zeigt, der einen Arbeitsablauf eines Compilers beim Kompilieren eines Teils des Quellcodes unter Verwendung von aggressiven Optimierungstechniken gemäß den Ausführungsbeispielen darlegt;
6 ein Ablaufplan ist, der einen beispielhaften Arbeitsablauf bei der Ausführung eines Computerprogramms gemäß einem Ausführungsbeispiel darlegt;
7 ein Ablaufplan ist, der einen beispielhaften Arbeitsablauf bei der Ausführung eines Computerprogramms gemäß einem Ausführungsbeispiel darlegt, das einen Vorhersagemechanismus zum Ermitteln verwendet, ob eine aggressiv kompilierte Version eines Teils eines Codes ausgeführt werden soll oder nicht;
8A ein beispielhaftes Quellcodeprogramm zum Ausführen von skalaren Operationen ist, die durch einen Compiler vektorisiert werden können, um eine optimierte Programmversion zu erzeugen;
8B ein Programm zur Ausführung eines umgewandelten Quellcodes ist, das die Umwandlungen zeigt, die ein Compiler zum Optimieren des Programms durch Vektorisieren der Arbeitsschritte von 8A durchführen kann, die jedoch möglicherweise das Verhalten eines Programms in Bezug auf Ausnahmebedingungen verändern; und
8C ein umgewandeltes Programm zur Ausführung eines Quellcodes ist, das einen aggressiv kompilierten Codeblock gemäß der Umwandlung von 8B im Rahmen einer Transaktion gemäß einem Ausführungsbeispiel zeigt.
BESTE AUSFÜHRUNGSWEISEN DER ERFINDUNG
Die Ausführungsbeispiele stellen einen Mechanismus zur aggressiven Optimierung durch einen Compiler in einem System bereit, der das Annullieren der durch den aggressiv kompilierten Code vorgenommenen Änderungen unterstützt, z. B. ein System, das Transaktionsspeicherstrukturen oder andere Arten atomarer Operationen nutzt. Gemäß einigen Ausführungsbeispielen nutzen die Mechanismen der Ausführungsbeispiele das atomare Verhalten des Systems, z. B. das atomare Verhalten eines Transaktionssystems, zur Ermittlung, ob eine aggressive Optimierung durch den Compiler zu einer fehlerhaften Funktion des umgewandelten und optimierten Codes führt, z. B. zur Verletzung einer Randbedingung, zur Konkurrenzsituation zwischen Threads usw., und nehmen in diesem Fall die durch die Ausführung des aggressiv optimierten Codes vorgenommenen Änderungen zugunsten einer weniger oder nicht optimierten Version des Codes zurück. Obwohl zur Beschreibung der folgenden Ausführungsbeispiele ein Transaktionssystem verwendet wird, sollte klar sein, dass die vorliegende Erfindung nicht darauf beschränkt ist und vielmehr jedes System verwendet werden kann, welches das Annullieren der durch eine aggressiv kompilierte Codeversion vorgenommenen Änderungen ermöglicht, z. B. ein System, das atomare Operationen unterstützt, um die Mechanismen der Ausführungsbeispiele zu realisieren, ohne von der sachlich-gegenständlichen Reichweite und dem Wesensgehalt der vorliegenden Erfindung abzuweichen.
Viele Systeme verwenden atomare Operationen. Bei einer atomaren Operation handelt es sich um eine Reihe von zwei oder mehr Operationen, die miteinander kombiniert werden können, sodass sie dem Datenverarbeitungssystem, in dem sie ausgeführt werden, wie eine einzige Operation erscheinen, die nur zwei mögliche Ergebnisse zulässt: Erfolg oder Fehlschlag. Bei einer atomaren Operation haben die Operationen in anderen Kombinationen keine Kenntnis von den Änderungen, die innerhalb der ersteren Kombination von Operationen vorgenommen wurden, welche die atomare Operation ausmachen, bis die gesamte Reihe von Operationen ausgeführt worden ist. Wenn bei einer atomaren Operation eine der Operationen innerhalb der Kombination von Operationen fehlschlägt, schlägt außerdem die ganze Reihe von Operationen fehl, und das System wird wieder in den Zustand zurückversetzt, den das System inne hatte, bevor die Ausführung der Operationen innerhalb der Reihe von Operationen begonnen hatte.
Bei einer atomaren Commitoperation handelt es sich um eine Operation, bei der eine Reihe einzelner Änderungen in Form einer einzigen Operation vorgenommen wird. Die atomare Commitoperation gilt als erfolgreich ausgeführt, wenn die Änderungen alle vorgenommen worden sind. Wenn vor Abschluss der atomaren Commitoperation ein Fehler auftritt, wird die „Commitoperation” abgebrochen, und alle vorgenommenen Änderungen werden rückgängig gemacht oder annulliert. Auf jeden Fall belässt die atomare Commitoperation das System in einem unveränderten Zustand. Atomare Commitoperationen werden oft in Datenbanksystemen verwendet, wenn gleichzeitig mehrere Gruppen von Änderungen vorgenommen werden. Atomare Commitoperationen werden von Versionsverwaltungssystemen (revision control system, RCS) verwendet, wobei die atomaren Commitoperationen zur Steuerung des Hochladens der Änderungen mehrerer Dateien in eine Quelle der Dateien dienen und dabei garantieren, dass alle Dateien vollständig hochgeladen und eingefügt werden. Atomare Commitoperationen werden auch von zahlreichen Transaktionsverarbeitungssystemen (Geldautomaten, Onlinehandel usw.) verwendet, bei denen die Operationen auf verschiedenen Systemen (z. B. Auftragserteilung, Kreditkartentransaktionen, Bestandsaktualisierung) zu einer einzigen Folge von Operationen kombiniert werden, die als Gruppe insgesamt erfolgreich sind oder fehlschlagen.
Atomare Commitoperationen erweisen sich auch auf dem Gebiet der Transaktionsspeicher sowie des spekulativen Multithreading als brauchbar, das auch unter der Bezeichnung thread-level speculation (Spekulation auf Threadebene) bekannt ist. Ein Transaktionsspeicher ist bestrebt, gleichzeitige oder parallele Programmierschritte zu vereinfachen, indem er zulässt, dass eine Gruppe von Lade- und Speicher-Anweisungen atomar ausgeführt werden, sodass sichergestellt ist, dass entweder (1) alle Anweisungen der Transaktion erfolgreich ausgeführt werden oder (2) die Anweisungen der Transaktion keine Auswirkungen zur Folge haben. Bei atomaren Transaktionen hat es den Anschein, als würden die Anweisungen der Transaktion zwischen dem Aufrufen und dem Erzeugen der Ergebnisse gleichzeitig ausgeführt.
Hardwaresysteme von Transaktionsspeichern können Änderungen an den Prozessoren, den Cachespeichern und den Busprotokollen vornehmen, um die Transaktionen oder Transaktionsblöcke zu unterstützen, d. h. Gruppen von Anweisungen, die atomar als eine einzige Einheit ausgeführt werden sollen. Transaktionsspeicher auf Softwarebasis verwenden eine Transaktionsspeichersemantik in einer Software-Laufzeitbibliothek. Der Transaktionsspeicher auf Softwarebasis kann mit einer Hardwareunterstützung kombiniert werden, um einen Transaktionsspeicher als Hybridsystem zu konstruieren.
Der Begriff des Transaktionsspeichers wurde von Herlihy und Moss in dem Artikel „Transactional Memory: Architectural Support for Lock-Free Data Structures", Proceedings of the 20th Annual International Symposium an Computer Architecture, Mai 1993, S. 289 bis 300, eingeführt. Wie Bobba et al. jedoch in dem Artikel „Performance Pathologies in Hardware Transactional Memory", ISCA '07, 9. bis 13. Juni 2007, beschreiben, kann ein Programmierer eine Transaktion in einer Multithreadanwendung aufrufen und sich des Transaktionsspeichersystems bedienen, damit deren Ausführung in einer insgesamt seriellen Reihenfolge wie eine atomare Operation erscheint. Bobba et al. erörtern Methoden zur Konfliktlösung in Transaktionsspeichersystemen.
Transaktionsspeichersysteme streben höhere Leistungswerte an, indem sie mehrere Transaktionen spekulativ gleichzeitig ausführen und nur solche Transaktionen zulassen, die keine Konflikte verursachen. Zu einem Konflikt kommt es, wenn zwei oder mehr Transaktionen gleichzeitig auf ein und dasselbe Datenelement, z. B. ein Wort, einen Block, ein Objekt usw., zugreifen und mindestens ein Zugriff eine Schreiboperation ist. Transaktionsspeichersysteme können bestimmte Konflikte durch Zurückstellen einer oder mehrerer Transaktionen lösen.
Das spekulative Multithreading ist eine spekulative Ausführungsart, die nicht auf Anweisungsebene, sondern auf Threadebene erfolgt. Beim spekulativen Multithreading handelt es sich eine dynamische Parallelverarbeitungstechnik, bei der die Anweisungen mehrerer Threads abweichend von der normalen Reihenfolge verarbeitet werden, um die Arbeitsgeschwindigkeit von Prozessoren zu erhöhen. Durch das spekulative Multithreading können die durch die Threads vorgenommenen Änderungen in atomaren Schritten vorgenommen werden, wenn die Beziehungen zwischen den Threads nicht verletzt wurden. Spezielle Hardware verfolgt die Datenspeicherorte der spekulativen Lese-(Lade-) und Schreib-(Speicher-)operationen der Threads und bricht Threads ab, d. h. annulliert oder hebt diese auf, die eine existierende Datenbeziehung verletzt haben, d. h. an einer Konkurrenzsituation beteiligte Threads.
Mittels der Mechanismen der Ausführungsbeispiele erzeugt ein Compiler zwei kompilierte Versionen desselben Teils des Quellcodes. Eine erste kompilierte Version des Teils des Quellcodes wird als aggressiv kompilierter Code bezeichnet, da der Compiler alle möglichen Umwandlungen und Optimierungen des Original-Quellcodes vornimmt, ohne auf mögliche Verletzungen von Grenzfällen, Unterlaufbedingungen (z. B. Division durch null), Überlaufbedingungen (z. B. Division durch unendlich), Konkurrenzsituationen auf Threadebene usw. zu achten, die bei dem umgewandelten Code eintreten können. Im weitesten Sinne handelt es sich bei dem aggressiv kompilierten Code um einen Code, bei dem alle möglichen Umwandlungen und Optimierungen durchgeführt werden, die nicht immer gültig sind und dann annulliert werden können, um den ursprünglichen Zustand wiederherzustellen. Das lässt sich sogar auf bisher unbekannte Optimierungstechniken anwenden. Wesentlich ist, dass die normalen Arbeitsschritte des Compilers in Bezug auf Abbrüche oder den Verzicht auf Umwandlungen, wenn der Compiler erkennt, dass eine Verletzung eintreten kann, aufgehoben werden, um diese erste kompilierte Version des Teils des Quellcodes zu erstellen.
Eine zweite kompilierte Version des Teils des Quellcodes wird als der konservativ kompilierte Code bezeichnet, da der Compiler keine Optimierungen durchführt, die zu einer Verletzung oder einer Abweichung vom vorgesehenen Ablauf des Quellcodes führen kann, z. B. werden keine Optimierungen durchgeführt, die zu einem umgewandelten Code führen können, der eine Randbedingung verletzen, eine Konkurrenzsituation auf Threadebene oder Ähnliches erzeugen kann. Der konservativ kompilierte Code ist weniger gut optimiert als der aggressiv kompilierte Code, da der konservativ kompilierte Code üblicherweise nicht alle möglichen verfügbaren Optimierungen wie der aggressiv kompilierte Code aufweist. Beispiele von aggressiv kompiliertem Code und konservativ kompiliertem Code sind in 8A und 8B angegeben, die im Folgenden beschrieben werden.
Während der Ausführung des kompilierten Codes wird versucht, den aggressiv kompilierten Code im Rahmen einer Transaktion auszuführen und nach einer Ausnahmebedingung zu suchen, z. B. der Verletzung einer Randbedingung, einer Konkurrenzsituation auf Threadebene oder Ähnliches. Falls eine solche Ausnahmebedingung auftreten sollte, wird die Steuerung an einen Transaktionsmanager übergeben. Der Transaktionsmanager umfasst eine Logik, die in Form von Hardware, Software oder einer Kombination von Hardware und Software realisiert werden kann, um die Ausführung des Codes zu annullieren und in einen Zustand vor der Ausführung des aggressiv kompilierten Codeteils zurückzuführen, der die Ausnahmebedingung verursacht hat. Dann versucht der Transaktionsmanager den Teil des Codes unter Verwendung des konservativ kompilierten Codes erneut auszuführen. Auf diese Weise wird ein automatisierter Mechanismus bereitgestellt, der die Ausführung des aggressiv kompilierten Codes in den meisten Fällen zulässt, wobei der konservativ kompilierte Code nur dann ausgeführt wird, wenn der aggressiv kompilierte Code fehlschlägt, d. h. eine Ausnahmebedingung verursacht.
Da die Operationen zur Annullierung und zur erneuten Codeausführung bezüglich der zur Ausführung einer solchen Operation erforderlichen Prozessorzyklen aufwendig sind, wird gemäß einem weiteren Ausführungsbeispiel ein Vorhersagemechanismus bereitgestellt, um zu ermitteln, ob es möglicherweise zu einer Rücknahme kommt. Diese Ermittlung kann sich auf ein Vorhersageschema auf der Grundlage der Vorgeschichte, die Ergebnisse einer Analyse des Codes oder Ähnliches stützen. Als Reaktion auf eine Vorhersage, dass eine Annullierung wahrscheinlich ist, versuchen die Mechanismen der Ausführungsbeispiele nicht den aggressiv kompilierten Code, sondern den konservativ kompilierten Code auszuführen, um die wahrscheinlich gewordenen Operationen der Annullierung und der erneuten Ausführung zu vermeiden.
Dem Fachmann ist einsichtig, dass die vorliegende Erfindung als System, als Verfahren oder als Computerprogrammprodukt realisiert werden kann. Demzufolge können Aspekte der vorliegenden Erfindung die Form einer vollständigen Hardware-Ausführungsform, einer vollständigen Software-Ausführungsform (einschließlich Firmware, residenter Software, Mikrocode usw.) oder einer Ausführungsform annehmen kann, die Software- und Hardwareaspekte in sich vereint und die hierin sämtlich allgemein als „Schaltkreis”, „Modul” oder „System” bezeichnet werden können. Darüber hinaus können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien mit einem darauf verkörperten Programmcode verkörpert ist, der durch einen Computer verwendet werden kann.
Es können beliebige Kombinationen von einem oder mehreren computerlesbaren Medien verwendet werden. Bei dem computerlesbaren Medium kann es sich um ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium handeln. Als computerlesbares Speichermedium kann zum Beispiel, im Sinne einer nicht abschließenden Aufzählung, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine entsprechende Vorrichtung, Einheit oder deren geeignete Kombination dienen. Speziellere Beispiele (eine nicht abschließende Aufzählung) für das computerlesbare Medium können Folgendes beinhalten: eine elektrische Verbindung mit einem oder mehreren Drähten, eine tragbare Computerdiskette, eine Festplatte, einen Arbeitsspeicher (random access memory, RAM), einen Nur-Lese-Speicher (read-only memory, ROM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM oder Flashspeicher), einen Lichtwellenleiter, eine tragbare CD-ROM (compact disc readonly-memory), eine optische Speichereinheit, eine magnetische Speichereinheit oder deren beliebige Kombination. Im Zusammenhang mit diesem Dokument kann es sich bei dem computerlesbaren Medium um ein beliebiges materielles Medium handeln, das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zum Ausführen von Anweisungen enthalten oder speichern kann.
Als computerlesbares Signalmedium kann ein weitergeleitetes Datensignal mit einem darin verkörperten computerlesbaren Programmcode infrage kommen, zum Beispiel in einem Basisband oder als Teil einer Trägerwelle. Ein solches weitergeleitetes Signal kann eine Vielzahl von Formen annehmen, darunter im Sinne einer nicht abschließenden Aufzählung elektromagnetische und optische Signale oder deren geeignete Kombinationen. Bei einem computerlesbaren Signalmedium kann es sich um jedes computerlesbare Medium handeln, das kein computerlesbares Speichermedium ist und das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Ausführung von Anweisungen übertragen, weiterleiten oder befördern kann.
Ein auf einem computerlesbaren Medium verkörperter Computercode kann unter Verwendung eines geeigneten Mediums übertragen werden, darunter im Sinne einer nicht abschließenden Aufzählung drahtlos, leitungsgebunden, Lichtwellenleiter, Hochfrequenz (HF) usw. oder deren geeignete Kombinationen.
Der Computerprogrammcode zum Ausführen von Operationen gemäß Aspekten der vorliegenden Erfindung kann in einer beliebigen Kombination einer oder mehrerer Programmiersprachen geschrieben sein, darunter objektorientierte Programmiersprachen wie beispielsweise Java^TM, Smalltalk^TM, C++ oder ähnliche und herkömmliche prozedurale Programmiersprachen wie beispielsweise die Programmiersprache „C” oder ähnliche Programmiersprachen. Der Programmcode kann vollständig auf dem Computer eines Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. Im letzteren Fall kann der ferne Computer über einen beliebigen Netzwerktyp mit dem Computer des Benutzer verbunden sein, darunter ein lokales Netz (local area network, LAN) oder ein Weitverkehrsnetz (wide area network, WAN), oder die Verbindung kann zu einem externen Computer über das Internet unter Verwendung eines Internet-Dienstanbieters hergestellt werden.
Im Folgenden werden Aspekte der vorliegenden Erfindung unter Bezug auf die Ablaufpläne und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß den Ausführungsbeispielen der Erfindung beschrieben. Es ist klar, dass jeder Block der Ablaufpläne und/oder Blockdiagramme und Kombinationen von Blöcken in den Ablaufplänen und/oder Blockdiagrammen durch Anweisungen eines Computerprogramms realisiert werden können. Diese Anweisungen von Computerprogrammen können durch einen Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine derart zu schaffen, dass die durch den Prozessor des Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zum Umsetzen der Funktionen/Aktionen erzeugen, die in dem Block oder den Blöcken des Ablaufplans und/oder Blockdiagramms angegeben sind.
Diese Anweisungen des Computerprogramms können auch in einem computerlesbaren Medium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten dazu veranlassen kann, auf eine bestimmte Weise zu funktionieren, sodass die in dem computerlesbaren Medium gespeicherten Anweisungen einen Herstellungsartikel erzeugen, der Anweisungen zum Umsetzen der in dem Block oder den Blöcken des Ablaufplans und/oder des Blockdiagramms angegebenen Funktion/Aktion beinhaltet.
Die Anweisungen des Computerprogramms können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um die Ausführung einer Reihe von Arbeitsschritten auf dem Computer, der anderen programmierbaren Vorrichtung oder anderen Einheiten zu veranlassen, damit ein computergestützter Prozess derart in Gang gesetzt wird, dass die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführten Anweisungen Prozesse zum Umsetzen der in dem Block oder den Blöcken des Ablaufplans und/oder Blockdiagramms angegebenen Funktionen/Aktionen bereitstellen.
Der Ablaufplan und die Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und die Arbeitsweise möglicher Ausführungsarten von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Diesbezüglich kann jeder Block in dem Ablaufplan oder den Blockdiagrammen ein Modul, ein Segment oder einen Codebestandteil repräsentieren, der eine oder mehrere ausführbare Anweisungen zum Umsetzen der angegebenen Logikfunktionen umfasst. Dabei ist zu beachten, dass bei einigen alternativen Ausführungsformen die in dem Block angegebenen Funktionen in einer von den Figuren abweichenden Reihenfolge ausgeführt werden können. Zum Beispiel können je nach der vorgesehenen Funktionalität zwei nacheinander dargestellte Blöcke in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in umgekehrter Reihenfolge ausgeführt werden. Ferner ist zu beachten, dass jeder Block in der Darstellung der Blockdiagramme und/oder des Ablaufplans und Kombinationen von Blöcken in der Darstellung der Blockdiagramme und/oder des Ablaufplans durch speziell eingerichtete Hardwaresysteme, die die betreffenden Funktionen oder Aktionen ausführen, oder durch Kombinationen von spezieller Hardware und von Computeranweisungen umgesetzt werden kann.
Unter Bezugnahme auf die Figuren und insbesondere auf 1 und 2 werden nunmehr beispielhafte Schaubilder von Datenverarbeitungsumgebungen bereitgestellt, in denen Ausführungsbeispiele der vorliegenden Erfindung umgesetzt werden können. Es sollte einsichtig sein, dass 1 und 2 nur Beispiele darstellen und nicht als Einschränkung in Bezug auf die Umgebungen anzusehen sind, in denen Aspekte oder Ausführungsformen der vorliegenden Erfindung realisiert werden können. An den dargestellten Umgebungen können zahlreiche Änderungen vorgenommen werden, ohne von der sachlich-gegenständlichen Reichweite und dem Wesensgehalt der vorliegenden Erfindung abzuweichen.
Unter Bezugnahme auf die Figuren stellt 1 nunmehr eine bildliche Darstellung eines beispielhaften verteilten Datenverarbeitungssystems dar, in dem Aspekte der Ausführungsbeispiele umgesetzt werden können. Ein verteiltes Datenverarbeitungssystem 100 kann ein Netz von Computern beinhalten, in denen Aspekte der Ausführungsbeispiele umgesetzt werden können. Das verteilte Datenverarbeitungssystem 100 enthält mindestens ein Netz 102, welches das Medium zum Bereitstellen von Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Computern darstellt, die innerhalb des verteilten Datenverarbeitungssystems 100 miteinander verbunden sind. Das Netz 102 kann Verbindungen beinhalten, beispielsweise ein Kabel, drahtlose Datenübertragungsverbindungen oder Lichtwellenleiter.
Bei dem dargestellten Beispiel sind ein Server 104 und ein Server 106 zusammen mit einer Speichereinheit 108 mit dem Netz 102 verbunden. Außerdem sind auch Clients 110, 112 und 114 mit dem Netz 102 verbunden. Bei diesen Clients 110, 112 und 114 kann es sich zum Beispiel um Personal Computer, Netzcomputer oder Ähnliches handeln. Bei dem dargestellten Beispiel liefert der Server 104 Daten wie beispielsweise Bootdateien, Abbilder von Betriebssystemen und Anwendungen an die Clients 110, 112 und 114. Bei dem dargestellten Beispiel sind die Clients 110, 112 und 114 dem Server 104 untergeordnete Clients. Das verteilte Datenverarbeitungssystem 100 kann weitere Server, Clients und andere nicht gezeigte Einheiten beinhalten.
Bei dem dargestellten Beispiel dient als verteiltes Datenverarbeitungssystem 100 das Internet, wobei das Netz 102 eine weltweite Ansammlung von Netzen und Gateways repräsentiert, die eine Reihe von Protokollen in Form des TCP/IP (Transmission Control Protocol/Internet Protocol) nutzen, um Daten untereinander auszutauschen. Das Herzstück des Internets stellen Datenleitungen zur Hochgeschwindigkeitsübertragung (Backbone) zwischen Hauptknoten oder Hostrechnern dar, die aus Tausenden von Computersystemen von Wirtschaft, Regierung, Bildungswesen und anderen Bereichen bestehen, die Daten und Nachrichten weiterleiten. Natürlich kann das verteilte Datenverarbeitungssystem 100 auch so gestaltet werden, dass es eine Anzahl unterschiedlicher Arten von Netzen beinhaltet, zum Beispiel ein Intranet, ein lokales Netz (LAN), ein Weitverkehrsnetz (WAN) oder Ähnliches. Gemäß den obigen Ausführungen dient 1 lediglich als Beispiel, nicht jedoch als Einschränkung für die Architektur verschiedener Ausführungsformen der vorliegenden Erfindung, und die einzelnen in 1 gezeigten Elemente sind nicht als Einschränkung in Bezug auf die Umgebungen anzusehen, in denen die Ausführungsbeispiele der vorliegenden Erfindung umgesetzt werden können.
Unter Bezugnahme auf 2 wird nunmehr ein Blockdiagramm eines beispielhaften Datenverarbeitungssystems gezeigt, in dem Aspekte von Ausführungsbeispielen umgesetzt werden können. Bei dem Datenverarbeitungssystem 200 handelt es sich um ein Beispiel eines Computers wie beispielsweise des Clients 110 in 1, in dem ein durch den Computer ausführbarer Code oder Anweisungen zum Umsetzen der Prozesse für Ausführungsbeispiele der vorliegenden Erfindung gespeichert sein können.
Bei dem dargestellten Beispiel verwendet das Datenverarbeitungssystem 200 einen Hub (Zentralverteiler) 202 mit einer Northbridge und einer Speichersteuereinheit (NB/MCH) und einen Hub 204 mit einer Southbridge und einer Eingabe-/Ausgabesteuereinheit (E/A) 204. Die Verarbeitungseinheit 206, der Hauptspeicher 208 und die Grafikprozessoren 210 sind mit der NB/MCH 202 verbunden. Der Grafikprozessor 210 kann über einen schnellen Grafikanschluss (accelerated graphics port, AGB) mit der NB/MCH 202 verbunden sein.
Bei dem dargestellten Beispiel ist ein LAN-Adapter 212 mit der SB/ICH 204 verbunden. Ein Audioadapter 216, ein Tastatur- und Mausadapter 220, ein Modem 222, ein Nur-Lese-Speicher ROM 224, ein Festplattenlaufwerk (hard disk drive, HDD) 226, ein CD-ROM-Laufwerk 230, USB- sowie andere Datenübertragungsanschlüsse 232 und PCI/PCIe-Einheiten 234 sind durch den Bus 238 und den Bus 240 mit der SB/ICH 204 verbunden. PCI/PCIe-Einheiten können zum Beispiel Ethernet-Adapter, Steckkarten und PC-Karten für Notebook-Rechner beinhalten. Der PCI-Bus verwendet eine Karten-Bussteuereinheit, der PCIe-Bus hingegen nicht. Bei dem ROM 224 kann es sich um ein Flash-BIOS (basic input/output system) handeln.
Das HDD 226 und das CD-ROM-Laufwerk 230 sind durch den Bus 240 mit der SB/ICH 204 verbunden. Das HDD 226 und das CD-ROM-Laufwerk 230 können zum Beispiel eine integrierte Laufwerkelektronik (integrated drive electronics, IDE) oder eine SATA-Schnittstelle (serial advanced technology attachment, serieller Zusatz für fortgeschrittene Technik) verwenden. Die SIO-Einheit 236 (super I/O, Supereingabe/-ausgabe) kann mit der SB/ICH 204 verbunden sein.
Auf der Verarbeitungseinheit 206 wird ein Betriebssystem ausgeführt. Das Betriebssystem koordiniert und steuert verschiedene Komponenten innerhalb des Datenverarbeitungssystems 200 in 2. Als Betriebssystem für den Client kann ein handelsübliches Betriebssystem wie beispielsweise Microsoft^® Windows^® XP verwendet werden (Microsoft und Windows sind Warenzeichen von Microsoft Corporation in den vereinigten Staaten von Amerika, anderen Ländern oder beiden). Ein objektorientiertes Programmiersystem wie beispielsweise das Java^TM-Programmiersystem kann in Verbindung mit dem Betriebssystem ausgeführt werden und sendet Aufrufe von Java^TM-Programmen oder -Anwendungen, die auf dem Datenverarbeitungssystem 200 ausgeführt werden, an das Betriebssystem (Java ist ein Warenzeichen von Sun Microsystems, Inc., in den Vereinigten Staaten von Amerika, anderen Ländern oder beiden).
Als Server kann das Datenverarbeitungssystem 200 zum Beispiel ein Computersystem IBM^® eServer^TM System p^® sein, auf dem das Betriebssystem Advanced Interactive Executive (AIX^®) oder das Betriebssystem LINUX^® ausgeführt wird (eServer, System p und AIX sind Warenzeichen von International Business Machines Corporation in den Vereinigten Staaten von Amerika, anderen Ländern oder beiden, während LINUX ein Warenzeichen von Linus Torvalds in den Vereinigten Staaten von Amerika, anderen Ländern oder beiden ist). Als Datenverarbeitungssystem 200 kann ein symmetrisches Multiprozessorsystem (SMP) dienen, das eine Vielzahl von Prozessoren in der Verarbeitungseinheit 206 enthält. Alternativ kann ein Einprozessorsystem verwendet werden.
Anweisungen für das Betriebssystem, das objektorientierte Programmiersystem und Anwendungen oder Programme befinden sich auf Speichereinheiten wie beispielsweise dem HDD 226 und können zur Ausführung durch die Verarbeitungseinheit 206 in den Arbeitsspeicher 208 geladen werden. Die Prozesse für die Ausführungsbeispiele der vorliegenden Erfindung können durch die Verarbeitungseinheit 206 unter Verwendung eines durch den Computer ausführbaren Programmcodes durchgeführt werden, der sich in einem Speicher wie beispielsweise im Arbeitsspeicher 208, im ROM 224 oder in einer oder mehreren Peripherieeinheiten wie beispielsweise 226 und 230 befinden kann.
Ein Bussystem wie beispielsweise der Bus 238 oder der Bus 240, die in 2 gezeigt sind, kann aus einem oder mehreren Bussen bestehen. Natürlich kann das Bussystem unter Verwendung einer beliebigen Art von Datenübertragungsnetz oder -architektur realisiert werden, welche die Datenübertragung zwischen verschiedenen an das Netz oder die Architektur angeschlossenen Komponenten oder Einheiten ermöglichen. Eine Datenübertragungseinheit wie beispielsweise ein Modem 222 oder ein Netzadapter 212 von 2 kann eine oder mehrere Einheiten zum Senden und Empfangen von Daten beinhalten. Als Speicher kann zum Beispiel der Arbeitsspeicher 208, der ROM 224 oder ein Cachespeicher dienen, wie er in der NB/MCH 202 in 2 zu finden ist.
Dem Fachmann ist einsichtig, dass die Hardware in 1 und 2 je nach der Ausführungsart variieren kann. Zusätzlich zu oder anstelle der in 1 und 2 dargestellten Hardware können andere interne Hardware- oder Peripherieeinheiten wie beispielsweise ein Flash-Speicher, ein gleichwertiger Permanentspeicher oder optische Plattenlaufwerke und Ähnliches verwendet werden. Ferner können die Prozesse der Ausführungsbeispiele auf einem anderen Multiprozessor-Datenverarbeitungssystem als dem oben erwähnten SMP-System ausgeführt werden, ohne von der sachlich-gegenständlichen Reichweite und dem Wesensgehalt der vorliegenden Erfindung abzuweichen.
Darüber hinaus kann das Datenverarbeitungssystem 200 die Form einer Anzahl verschiedener Datenverarbeitungssysteme annehmen, die Client-Recheneinheiten, Server-Recheneinheiten, einen Tablet-Computer, einen Laptop-Computer, ein Telefon oder andere Datenübertragungseinheiten, einen persönlichen digitalen Assistenten (PDA) oder Ähnliches beinhalten. Bei einigen anschaulichen Beispielen kann als Datenverarbeitungssystem 200 eine tragbare Recheneinheit dienen, die mit einem Flash-Speicher als Permanentspeicher ausgestattet ist, um zum Beispiel Betriebssystemdateien und/oder durch einen Benutzer erzeugte Daten zu speichern. Im Wesentlichen kann es sich bei dem Datenverarbeitungssystem 200 um ein beliebiges bekanntes oder in Zukunft zu entwickelndes Datenverarbeitungssystem ohne Architektureinschränkung handeln.
Gemäß einem Ausführungsbeispiel realisiert das Datenverarbeitungssystem 200 ein Transaktionsspeichersystem. Gemäß einem Ausführungsbeispiel kann es sich bei diesem Transaktionsspeichersystem um ein oben erörtertes HASTM-System handeln. In der Technik ist allgemein bekannt, dass in einem Transaktionsspeichersystem Transaktionen, die sich nicht überlappen, parallel ohne Unterbrechung weiter ausgeführt werden können, wobei aus Gründen der Datenkonsistenz Teile des Programms in atomaren Operationen, d. h. in atomaren Transaktionen, ausgeführt werden müssen, wobei die Transaktionsspeichersysteme zulassen, dass die Programme Speicherplätze in einer einzigen atomaren Operation lesen und ändern können. Bei Transaktionsspeichersystemen stellt eine Transaktion eine endliche Folge von Schritten oder Programmanweisungen dar, die durch einen einzelnen Thread ausgeführt werden. Eine Transaktion kann seriell ausgeführt werden, sodass sich die Schritte oder Anweisungen einer Transaktion nicht mit den Schritten oder Anweisungen einer anderen Transaktion überlappen. Transaktionsspeichersysteme stellen einen Mechanismus bereit, mit dem die Atomizität von atomaren Schritten oder atomaren Transaktionen garantiert wird, indem sichergestellt wird, dass diese Speicherzugriffe für einen externen Beobachter gleichzeitig wirksam zu werden scheinen, d. h. ein atomarer Schritt ist entweder erfolgreich oder wird abgebrochen. Für nähere Informationen zu Transaktionsspeichersystemen wird auf die an denselben Anmelder abgetretene und gleichzeitig anhängige US-Patentanmeldung Nr. 12/046 764 unter dem Aktenzeichen 2009/0235254 verwiesen, die durch Bezugnahme hierin aufgenommen ist.
Die Ausführungsbeispiele bedienen sich dieses Transaktionsspeichersystems, um den aggressiv kompilierten Code als Transaktion auszuführen, der einfach wieder annulliert werden kann, um anschließend in einer weiteren Transaktion die Ausführung mit dem konservativ kompilierten Code zu wiederholen. Der Compiler, der diese beiden kompilierten Versionen eines Teils des Quellcodes erzeugt, kann auf demselben Datenverarbeitungssystem/-einheit ausgeführt werden, wie dasjenige, auf dem der kompilierte und verknüpfte Code ausgeführt wird, oder auf einem separaten Datenverarbeitungssystem/-einheit. Auf demselben oder einem anderen Datenverarbeitungssystem/-einheit wird auch ein Transaktionsmonitor ausgeführt, der die Ausführung des kompilierten und verknüpften Codes überwacht, um zu ermitteln, ob der aggressiv kompilierte Code erfolglos ist oder aufgrund der zum Erzeugen des aggressiv kompilierten Codes verwendeten aggressiven Optimierungen eine Ausnahmebedingung erzeugt. Wenn der aggressiv kompilierte Code erfolglos ist oder eine Ausnahmebedingung erzeugt, kann der Transaktionsmonitor die Transaktion wieder annullieren und anschließend die Ausführung mit der konservativ kompilierten Version des Teils des Codes wiederholen.
Zum besseren Verständnis des durch die Ausführungsbeispiele behandelten Problems zeigen 3A und 3B ein Beispiel für eine Codeoptimierung. 3A veranschaulicht eine Sequenz des Original-Quellcodes für einen Teil des Codes. Der Code in 3A stellt ein Beispiel für einen SIMD-Code (single instruction multiple data, Einzelanweisung mit mehreren Daten) dar, der normalerweise nicht parallel, sondern sequenziell ausgeführt wird. 3B veranschaulicht dieselbe Codesequenz nach der aggressiven Optimierung durch den Compiler, um den Teil des Codes zu vektorisieren, sodass er durch einen Vektorprozessor wirksamer ausgeführt werden kann. Insbesondere kann der vektorisierte Code unter Verwendung von Vektorelementen parallel ausgeführt werden. Eine Erklärung eines möglichen Mechanismus zum Umwandeln des SIMD-Codes in einen vektorisierten Code wird in der an denselben Anmelder abgetretenen und gleichzeitig anhängigen US-Patentanmeldung Nr. 12/250 575 beschrieben, die durch Bezugnahme hierin aufgenommen ist.
3A zeigt, dass die Original-Codesequenz auf die ersten 3 Werte des Feldes A zugreift und in den ersten drei Feldregistern X speichert. Dies erfolgt sequenziell und ist in Bezug auf die Verletzung von Randbedingungen ohne Belang. 3B veranschaulicht eine vektorisierte Form dieses Codes, der durch eine Optimierung durch den Compiler erzeugt werden kann. Wenn dieser Code auf diese Weise vektorisiert ist, wobei der Vektorcode Vektoren mit vier Elementen verwendet, werden die Felder in Blöcken zu je vier Elemente gelesen. Obwohl durch den Code gemäß 3C nur 3 Feldwerte genutzt werden, werden somit aufgrund der Vektorisierung 4 Werte geladen, sodass aufgrund der Vektorisierung auch a3 geladen wird, obwohl nur die Daten a0, a1 und a2 für den Teil des Codes korrekt gespeichert werden. Wenn a3 sich über eine Speicherseiten-Grenze 310 in einer Speicherseite 320 erstreckt, auf die das Programm nicht zugreifen kann, oder wenn sich a3 auf einer nicht vorhandenen Seite befindet und beim Laden eines Vektors diese Speicherseite tangiert wird, die dem Prozess nicht zugeordnet ist, wird dadurch ein Programmfehler angezeigt und das Betriebssystem veranlasst, eine Zugriffsverletzung anzuzeigen und die Anwendung normalerweise zu beenden. Zu einem Programmfehler kann es in einem Multithread-Code auch kommen, wenn sich a3 auf einem durch einen anderen Prozess verwendeten Speicherplatz befindet, sodass durch das Laden von a3 Daten beschädigt werden können, wenn der Wert a3 zurückgeschrieben wird, und möglicherweise Schreiboperationen zum Aktualisieren von a3 fehlerhaft erfolgen, die im Ausgangscode nicht vorhanden waren.
Bei Verwendung des obigen Beispiels führt der in 3A gezeigte Originalcode nicht zu einer Grenzwertbedingung und erzeugt somit keine Ausnahme. Die vektorisierte Version des Teils des Codes hingegen führt zur Verletzung einer Grenzwertbedingung und kann somit eine Ausnahmebedingung erzeugen, falls der Code versuchen sollte, auf Vektorelemente jenseits der Grenzen der Speicherseite zuzugreifen. Diese Ausnahmebedingung liegt im Originalcode nicht vor, wird jedoch mit der durch den Compiler eingeführten Optimierung eingeführt. Somit ermittelt der Compiler mittels bekannter Mechanismen, dass diese Optimierung mit diesem Teil des Codes nicht durchgeführt werden darf.
Gemäß Ausführungsbeispielen erzeugt der Compiler jedoch sowohl einen aggressiv kompilierten Code, dessen Optimierungen zu Ausnahmebedingungen führen können, wie sie zum Beispiel durch Verletzung von Grenzwertbedingungen möglich sind, als auch einen konservativ kompilierten Code für denselben Teil des Quellcodes. Mit anderen Worten, Optimierungen, die der Compiler ansonsten mit dem Teil des Codes möglicherweise nicht durchführen kann, werden aber tatsächlich mit dem Teil des Codes durchgeführt, um den aggressiv kompilierten Code ungeachtet der Tatsache zu erzeugen, ob der Compiler ermittelt, dass solche Optimierungen zu einer Ausnahmebedingung führen können, die unter bestimmten Bedingungen auftreten kann, wenn der optimierte und aggressiv kompilierte Code ausgeführt wird. Diese Optimierungen werden nicht durchgeführt, wenn der konservativ kompilierte Code erzeugt wird. Somit erzeugt der Compiler für jeden Teil des Quellcodes, für den der Compiler ermittelt, dass eine Optimierung zu einem kompilierten Code führen kann, der die vorgesehene Operation des Original-Quellcodes verletzen und eine Ausnahmesituation erzeugen kann, sowohl eine aggressiv kompilierte Version des Codes und eine konservativ kompilierte Version des Codes.
Wenn der aggressiv kompilierte Code auf einem Datenverarbeitungssystem/-einheit ausgeführt wird, die ein Transaktionsspeichersystem verwendet, wird er als eine einzige Transaktion ausgeführt. Zum Beispiel können bei Verwendung des in 3B gezeigten aggressiv kompilierten Codes Anweisungen in den Code eingefügt werden, um den Beginn und das Ende der Transaktion mit allen zwischen Beginn und Ende der Transaktion auftretenden Anweisungen anzuzeigen, die als einzelne Transaktion ausgeführt werden. Zum Beispiel kann der Code in 3B so umgewandelt werden, dass er eine Transaktion durch Einführen der folgenden (fett gedruckten) Anweisungen ausführt:
Somit werden innerhalb der Transaktion (zwischen den Anweisungen „transaction_begin” und „transaction_end”) alle Anweisungen in dem aggressiv kompilierten Code entweder erfolgreich abgeschlossen, oder keine der durch diese Anweisungen vorgenommenen Änderungen darf festgeschrieben werden. Die Ausführung der Transaktion wird durch einen Transaktionsmonitor überwacht, der sich in dem Datenverarbeitungssystem/-einheit oder in einem anderen Datenverarbeitungssystem/-einheit befindet, welches das erste Datenverarbeitungssystem/-einheit überwacht. Falls die Transaktion aufgrund einer oder mehrerer Anweisungen in der Transaktion fehlschlägt, die eine Ausnahme erzeugen, zum Beispiel als Reaktion auf die Verletzung einer Grenzwertbedingung, einer Konkurrenzsituation auf Threadebene oder Ähnliches, erkennt der Transaktionsmonitor diesen Fehler und löst das Annullieren der durch die Anweisungen der Transaktion vorgenommenen Änderungen aus. Dann löst der Transaktionsmonitor die wiederholte Ausführung des Teils des Codes durch Aufrufen des konservativ kompilierten Codes für diesen bestimmten Teil des Codes aus. Desgleichen kann durch die Verwendung von Transaktionen das Auftreten von Konkurrenzsituationen verhindert werden, die durch Kollision zwischen den durch solche potenziell unsicheren Optimierungen eingeführten Threads und durch die Atomizität der Aktualisierungen von Lese-/Änderungs-/Schreiboperationen geschaffen wurden, die als Ursache für solche Konkurrenzsituationen wie in 3B infrage kommen.
Damit der konservativ kompilierte Code als Reaktion auf ein Versagen des aggressiv kompilierten Codes aufgerufen werden kann, verfügt der Transaktionsmonitor über eine Datenstruktur zum Zuordnen oder Korrelieren der aggressiv kompilierten Codeversion zu der konservativ kompilierten Codeversion für einen Teil des Quellcodes. Der Transaktionsmonitor kann als Reaktion auf ein Fehlschlagen des aggressiv kompilierten Codes eine Suche in dieser Datenstruktur durchführen, um einen Zeiger auf die konservativ kompilierte Codeversion zu erhalten, sodass die Ausführung mit seiner konservativ kompilierten Codeversion wiederholt werden kann.
Der Transaktionsmonitor kann ferner alle Fehler des aggressiv kompilierten Codes protokollieren. Das Protokoll kann zum Beispiel eine Kennung des aggressiv kompilierten Codeteils und einen entsprechenden Zählerstand enthalten, wie oft dieser aggressiv kompilierte Codeteil während der Ausführung des Computerprogramms fehlgeschlagen ist. Dieses Protokoll kann während derselben oder einer nachfolgenden Ausführung des Computerprogramms verwendet werden, um durch den Transaktionsmonitor eine Vorhersageoperation auszuführen. Das heißt, vor der Ausführung der aggressiv kompilierten Codeversion eines Teils des Codes kann der Transaktionsmonitor eine Vorhersageoperation ausführen, um vorherzusagen, ob der aggressiv kompilierte Code wahrscheinlich fehlschlagen wird. Diese Vorhersage kann auf der Grundlage dieses Protokolls durchgeführt werden, in dem der Verlauf der vorhergehenden Ausführungen des aggressiv kompilierten Codes gespeichert ist. Wenn der Verlauf anzeigt, dass ein Fehlschlag wahrscheinlich ist, z. B. wenn die Anzahl der Fehlschläge in der Datenstruktur des Protokolls eine vorgegebene Anzahl übersteigt, kann der Transaktionsmonitor anstelle des aggressiv kompilierten Codes die Ausführung des konservativ kompilierten Codes auslösen, um den Rechenaufwand für die Operationen zum Annullieren und Wiederholen zu vermeiden. Ansonsten gibt der Transaktionsmonitor dem aggressiv kompilierten Code den Vorzug, der zuerst ausgeführt wird, wenn keine Vorhersage eines zu erwartenden Fehlschlags vorliegt. Aufgrund dieser Bevorzugung wird der konservativ kompilierte Code nur als Reaktion auf ein Fehlschlagen des aggressiv kompilierten Codes oder eine Vorhersage eines Fehlschlagens des aggressiv kompilierten Codes ausgeführt.
4 zeigt ein beispielhaftes Blockdiagramm der hauptsächlichen Funktionselemente gemäß einem Ausführungsbeispiel. 4 zeigt einen Compiler 410, der eine Logik 414 zur optimierten Codeerzeugung zum Umsetzen der Mechanismen der Ausführungsbeispiele in Bezug auf das Erzeugen von Codeversionen für Teile des Quellcodes aufweist. Der Compiler 410 erzeugt einen kompilierten Code 415 in Abschnitten, deren Größe das Ausführen als Transaktionen ermöglicht. Während des Kompilierens des Quellcodes 405 in diese kompilierten Codeabschnitte ermittelt der Compiler 410, ob die am Quellcode vorgenommenen Optimierungen zu einer Abweichung der Codefunktion von der Zielstellung des Quellcodes führen kann, z. B. wenn sich eine Grenzwertbedingung geändert haben kann. Das heißt, der Compiler 410 ermittelt, ob die aggressiv Optimierung des Quellcodes zu einer veränderten Semantik führt. Um diese Ermittlung durchführen zu können, kann dem Compiler 410 eine Liste der Optimierungen 412 zur Verfügung gestellt werden, die das Verhalten des Codes gegenüber dem Original-Quellcode wahrscheinlich verändern. Eine solche Liste 412 kann zum Beispiel auf der Grundlage vorheriger Beobachtungen durch den Benutzer erstellt werden. Die Liste 412 kann ferner Hinweise auf Attribute eines Teils des Codes beinhalten, die bei Optimierung für den Teil des Codes mit diesen Attributen wahrscheinlich eine Veränderung der Semantik verursachen dürften.
Wenn der Compiler 410 ermittelt, dass der Teil des Quellcodes, der gerade unter Verwendung aggressiver Optimierungen kompiliert wird, diese Attribute aufweist, und die in der Liste 412 aufgeführte Optimierung eine der aggressiven Optimierungen ist, kann der Compiler 410 auch eine konservativ kompilierte Version 430 desselben Teils des Quellcodes erzeugen. Somit werden für ein und denselben Teil des Quellcodes sowohl eine aggressiv kompilierte Version 420 als auch eine konservativ kompilierte Version 430 erzeugt und in dem kompilierten Code 415 bereitgestellt. Ferner erzeugt der Compiler 410 einen Eintrag in der Zuordnungsdatenstruktur 440, der die Zugehörigkeit zwischen der aggressiv kompilierten Version 420 und der konservativ kompilierten Version 430 anzeigt.
Der Compiler 410 überführt diese Versionen 420 und 430 in Transaktionen in dem kompilierten Computerprogramm 415. Um solche Versionen 420 und 430 des kompilierten Codes in Transaktionen zu überführen, führt der Compiler 410 Codeanweisungen zum Umsetzen der Transaktionen ein, d. h. einen Code, der Anfang und Ende einer Transaktion kennzeichnet und durch ein Transaktions-Datenverarbeitungssystem/-einheit 450 erkannt werden kann. Die Erzeugung von Codes für Transaktionen ist in der Technik allgemein bekannt und wird somit hierin nicht näher erläutert.
Der Compiler 410 liefert ein kompiliertes Computerprogramm, das die Codeversionen 420 und 430 sowie die Zuordnungsdatenstruktur 440 enthält, an einen Prozessor desselben oder eines anderen Datenverarbeitungssystems/-einheit 450. Das Datenverarbeitungssystem/-einheit 450 führt das Computerprogramm, das die Codeversionen 420 und 430 umfasst, aus. Die Ausführung wird durch die Überwachungslogik 465 eines Transaktionsmonitors 460 des Datenverarbeitungssystems/-einheit 450 überwacht, um zu ermitteln, ob die Ausführung der aggressiv kompilierten Codeversion 420 fehlschlägt. Sollte die Transaktion, welche die aggressiv kompilierte Codeversion 420 umfasst, fehlschlagen, verwirft die Überwachungslogik 465 des Transaktionsmonitors 460 die durch die Transaktion vorgenommenen Änderungen und durchsucht die Zuordnungsdatenstruktur 440, um eine entsprechende konservativ kompilierte Codeversion 430 zu ermitteln. Dann leitet die Überwachungslogik 465 des Transaktionsmonitors 460 die Ausführung zu der konservativ kompilierten Codeversion 430 um, die der aggressiv kompilierten Codeversion 420 entspricht, deren Transaktion fehlgeschlagen ist.
Das Fehlschlagen der aggressiv kompilierten Codeversion 420 kann anhand einer Ausnahmebedingung ermittelt werden, die durch die aggressiv kompilierte Codeversion 420 während deren Ausführung erzeugt wurde. Der Transaktionsmonitor 460 kann bei dem Datenverarbeitungssystem/-einheit als Ausnahmebehandlungsroutine oder als Interruptbehandlungsroutine für die aggressiv kompilierten Codeversionen 420 eingetragen sein. Die Ausnahmen können unter Verwendung des Mechanismus der Ausführungsbeispiele sofort behandelt werden, indem die Ausführung des Computerprogramms sofort unterbrochen wird. Alternativ können diese Ausnahmen aufgeschoben werden, wie in der an denselben Anmelder abgetretenen und gleichzeitig anhängigen US-Patentanmeldung Nr. 12/543 614, die durch Bezugnahme hierin aufgenommen ist, beschrieben wird, bis zu einem späteren Zeitpunkt ermittelt wird, ob die Ausnahme immer noch den Gesamtablauf des Computerprogramms beeinflusst.
Wahlweise kann der Transaktionsmonitor 460 ferner eine dem Computercode entsprechende Protokolldatenstruktur 470 verwalten, welche die durch den Transaktionsmonitor 460 ermittelten Fehlschläge registriert. Diese Protokolldatenstruktur 470 kann zur Fehlerbehebung des Computercodes und zur Vorhersage gemäß einem anderen Ausführungsbeispiel dienen. Das heißt der Transaktionsmonitor 460 kann wahlweise eine Vorhersagelogik 467 zum Vorhersagen beinhalten, ob eine aggressiv kompilierte Codeversion 420 bei Ausführung wahrscheinlich versagen wird. Eine solche Vorhersagelogik 467 kann den Verlauf der in der Protokolldatenstruktur 470 protokollierten Fehlschläge auswerten, um eine solche Vorhersage zu erstellen. Wenn eine bestimmte aggressiv kompilierte Codeversion 420 zum Beispiel während vorhergehender Ausführungen bereits in einer vorgegebenen Anzahl von Fällen versagt hat, kann die Vorhersagelogik 467 vorhersagen, dass diese wahrscheinlich wieder versagen dürfte. Dadurch kann die Überwachungslogik 465 des Transaktionsmonitors 460 die Ausführung zu der konservativ kompilierten Codeversion 430 umleiten, bevor versucht wird, die aggressiv kompilierte Codeversion 420 auszuführen.
Zu beachten ist, dass die beschriebene Vorhersageoperation auf der Protokolldatenstruktur 470 beruht, jedoch ist dies nicht Voraussetzung. Statt dessen oder zusätzlich zu der Protokolldatenstruktur 470 kann die Vorhersagelogik 467 eine Analyse des Teils des Codes vornehmen oder durch andere Operationen vorhersagen, ob die aggressiv kompilierte Codeversion 420 wahrscheinlich zu einem Versagen führen dürfte. Zum Beispiel kann eine Adresse geprüft und so ermittelt werden, ob die Adresse in einen vorgegebenen Bereich fällt, der einer Seitenbegrenzung benachbart ist. Bei einer Ausführungsform kann vorhergesagt werden, ob Adressen innerhalb eines Bereichs der Seitenbegrenzung einen Verweis auf eine Seite verletzen können, um dann die Ausführung sofort an eine konservativ kompilierte Codeversion zu übergeben, aber gleichzeitig mit einem zweiten Thread einer Multithread-Anwendung anhand der Transaktionen mögliche Konkurrenzbedingungen aufzuheben.
Somit können auf diese Weise durch den Compiler 410 aggressive Optimierungen eines Quellcodes mittels automatisierter Mechanismen zum Umleiten der Verarbeitung zu konservativer kompilierten Codeversionen vorgenommen werden, falls die aggressiv kompilierten Codeversionen fehlschlagen sollten. Dadurch wird gegenüber bekannten Kompiliertechniken eine Leistungssteigerung erreicht, die solche aggressiven Optimierungen selbst bei der geringsten Wahrscheinlichkeit vermeiden, dass die Optimierung zu einem Code führt, der die Semantik verändert und so möglicherweise eine Ausnahmebedingung erzeugen kann. In den Fällen, dass ein Benutzer eine solche Operation durch den Compiler außer Kraft setzt, kann der resultierende aggressiv optimierte Code Ausnahmebedingungen erzeugen, ohne dass die Möglichkeit besteht, einen konservativ kompilierten Code zu verwenden.
5 zeigt einen Ablaufplan, der die Funktionsweise eines Compilers beim Kompilieren eines Teils des Quellcodes unter Verwendung aggressiver Optimierungstechniken gemäß den Ausführungsbeispielen darlegt. Die Bearbeitung in 5 beginnt damit, dass der Compiler eine Optimierung auswählt, die auf einen Teil des Quellcodes angewendet werden soll (Schritt 510). Der Compiler ermittelt, ob die ausgewählte Optimierung zu einer Änderung der Semantik des Originalcodes führt, sodass die ursprünglich beabsichtigte Funktion des Quellcodes verändert wird oder der optimierte Code möglicherweise eine Ausnahmebedingung erzeugt, die in dem Original-Quellcode nicht erzeugt worden wäre (Schritt 520). Der Compiler kann zum Beispiel ermitteln, ob eine Vektorisierung, Parallel-if-Konvertierung oder andere Arten der Optimierung des Original-Quellcodes zu einem optimierten Code führen, durch den möglicherweise neue Ausnahmebedingungen eingeführt werden, die in dem Original-Quellcode nicht vorhanden waren. Dies wird als Feststellung bezeichnet, ob die Optimierung „sicher” ist oder nicht.
Wenn die Optimierung sicher ist, wird die Optimierung des Teils des Quellcodes durchgeführt, um einen aggressiv kompilierten Code zu erzeugen (Schritt 530). Wenn die Optimierung nicht sicher ist, erzeugt der Compiler sowohl eine aggressiv kompilierte Codeversion, bei der die unsichere Optimierung durchgeführt wird, und eine konservativ kompilierte Codeversion, bei der die unsichere Optimierung nicht durchgeführt wird (Schritt 540). Dann erzeugt der Compiler eine Zuordnung zwischen der aggressiv kompilierten Codeversion und der konservativ kompilierten Codeversion und speichert die Zuordnung in einer Zuordnungsdatenstruktur, die zusammen mit dem kompilierten Code dem Datenverarbeitungssystem zur Verfügung gestellt wird, das den kompilierten Code ausführen soll (Schritt 550). Diese Zuordnung kann dann durch den Transaktionsmonitor des Datenverarbeitungssystems genutzt werden, wenn der aggressiv kompilierte Code fehlschlägt oder eine Ausnahmebedingung erzeugt. Dann wird die Bearbeitung beendet. Obwohl 5 zeigt, dass die Bearbeitung beendet wird, kann die Bearbeitung tatsächlich jedoch mit jedem Teil des Quellcodes mit jeder für jeden Teil des Quellcodes durchgeführten Optimierung wiederholt werden.
6 zeigt einen Ablaufplan, der einen beispielhaften Arbeitsablauf der Ausführung eines Computerprogramms gemäß einem Ausführungsbeispiel darlegt. 6 zeigt, dass der Arbeitsablauf mit der Ausführung einer aggressiv kompilierten Codeversion eines Teils des Quellcodes als einzelne Transaktion beginnt (Schritt 610). Dann wird ermittelt, ob die Transaktion mit der aggressiv kompilierten Codeversion fehlschlägt (Schritt 620). Wenn die Transaktion nicht fehlschlägt, wird die Bearbeitung beendet. Wenn die Transaktion fehlschlägt, wird ein Transaktionsmonitor über den Fehlschlag benachrichtigt (Schritt 630). Der Transaktionsmonitor protokolliert den Fehlschlag (Schritt 640) und führt eine Suchoperation nach der aggressiv kompilierten Codeversion in einer Zuordnungsdatenstruktur durch, um eine entsprechende konservativ kompilierte Codeversion zu finden (Schritt 650). Dann leitet der Transaktionsmonitor die Ausführung zu der konservativ kompilierten Codeversion um (Schritt 660). Dann wird die Bearbeitung beendet. Obwohl 6 eine Beendigung zeigt, sollte klar sein, dass diese Bearbeitung mit jeder Ausführung derselben oder einer anderen aggressiv kompilierten Codeversion wiederholt werden kann.
7 zeigt einen Ablaufplan, der einen beispielhaften Ablauf der Ausführung eines Computerprogramms gemäß einem Ausführungsbeispiel darlegt, das einen Vorhersagemechanismus zum Ermitteln nutzt, ob eine aggressiv kompilierte Version eines Teils des Codes ausgeführt werden soll oder nicht. 7 zeigt, dass die Bearbeitung mit einer Suchoperation nach einer Kennung einer aggressiv kompilierten Codeversion in einer Protokolldatenstruktur beginnt (Schritt 710). Anhand des Ergebnisses der Suchoperation wird ermittelt, ob die aggressiv kompilierte Codeversion möglicherweise zu einem Fehler führen kann (Schritt 720). Wenn dies nicht der Fall ist, wird die Ausführung zu der aggressiv kompilierten Codeversion des Teils des Quellcodes als einzelne Transaktion umgeleitet (Schritt 730). Es wird ermittelt, ob die Transaktion mit der aggressiv kompilierten Codeversion fehlschlägt (Schritt 740). Wenn die Transaktion nicht fehlschlägt, wird die Bearbeitung beendet. Wenn die Transaktion fehlschlägt, wird ein Transaktionsmonitor über den Fehler benachrichtigt (Schritt 750). Der Transaktionsmonitor protokolliert den Fehler (Schritt 760) und führt eine Suchoperation nach der aggressiv kompilierten Codeversion in einer Zuordnungsdatenstruktur durch, um eine entsprechende konservativ kompilierte Codeversion zu finden (Schritt 770). Anschließend, oder wenn in Schritt 720 ermittelt wird, dass die aggressiv kompilierte Codeversion wahrscheinlich einen Fehler verursachen dürfte, leitet der Transaktionsmonitor die Ausführung zu der konservativ kompilierten Codeversion um (Schritt 780). Dann wird die Bearbeitung beendet. Obwohl aus 7 eine Beendigung zeigt, sollte klar sein, dass diese Bearbeitung mit jeder Ausführung derselben oder einer anderen aggressiv kompilierten Codeversion wiederholt werden kann.
Gemäß einem Ausführungsbeispiel entspricht die aggressiv kompilierte Codeversion eines Teils des Quellcodes einer vektorisierten Version des Teils des Quellcodes, der parallel ausgeführt wird, und die konservativ kompilierte Codeversion einer skalaren Version oder nicht vektorisierten Version des Teils des Quellcodes, die seriell ausgeführt wird. Gemäß diesem Ausführungsbeispiel wird in den meisten Fällen das Leistungsniveau der parallelen Ausführung erreicht, jedoch erfolgt die Ausführung auf der skalaren Ebene in der korrekten Reihenfolge, ein Feldelement nach dem anderen, indem als Reaktion auf eine während der Vektorausführung erkannte Ausnahmebedingung eine weniger aggressiv optimierte serielle Version ausgeführt wird.
8A bis 8C veranschaulichen die verschiedenen Codeversionen gemäß einer solchen Ausführungsform. 8A veranschaulicht den Original-Quellcode. 8B veranschaulicht eine vektorisierte Version des Teils des in 8A gezeigten Quellcodes, d. h. eine aggressiv kompilierte Codeversion. 8C veranschaulicht die in 8B gezeigte aggressiv kompilierte Codeversion in einer Transaktionsversion. 8B und 8C sind hierin in Form von Quellcode dargestellt, um die hier vorgestellten Konzepte zu verdeutlichen. Interne Darstellungen bedienen sich „Fensterobjektfunktionen” (intrinsics), d. h. Pseudofunktionen, die Maschinenoperationen entsprechen, beispielsweise vec_fma für eine kombinierte Multiplikations-Additions-Operation eines Vektors von Werten. Dem Fachmann ist sicher klar, dass der Compiler den Code, der hierin gemäß den beispielhaften Ausführungsformen als Quellcode dargestellt ist, gemäß den Ausführungsbeispielen in einem anderen Format darstellen kann.
Der in 8A gezeigte Original-Quellcode verursacht Ausnahmebedingungen für Verweis-Ausnahmebedingungen, die entweder Verletzungen von Speicherzugriffen auf eines der Felder a, b und c oder Gleitkomma-Ausnahmebedingungen entsprechen, die den elementbezogenen Berechnungen der Elemente 0, 1, 2 oder 3 für das jeweilige Element entsprechen. Der vektorisierte Code von 8B zeigt jedoch nicht dasselbe Ausnahmeverhalten an, das zum Fehlschlagen einiger Benutzeranwendungen führen kann. Gemäß den Ausführungsbeispielen wird der vektorisierte Code von 8B in eine Transaktion gemäß 8C überführt, und wenn eine Ausnahmebedingung erkannt wird, wird die Transaktion abgebrochen, was zum Annullieren aller Vektorberechnungen führt. Dann kann ein Transaktionsmonitor die Bearbeitung an eine serielle Version dieses Codes übergeben, beispielsweise an die serielle Version gemäß 8A (wo wahlweise keine Transaktionen verwendet werden). Die Ausnahmebedingung wird entsprechend dem Verhalten des Originalprogramms auf der Elementebene für die Elemente 0, 1, 2 oder 3 angezeigt.
Somit können mittels der Mechanismen der Ausführungsbeispiele aggressive Optimierungen wie beispielsweise Vektorisierung, Parallel-if-Konvertierung, Multithreading und Ähnliches auch in Fällen durchgeführt werden, bei denen Optimierungen als unsicher erkannt wurden. Wenn sich erweist, dass die Optimierung während der Ausführung unsicher ist, kann die Ausführung darüber hinaus annulliert und die Bearbeitung zur der sicheren Version des Codes umgeleitet werden.
Wie oben erwähnt können die Mechanismen der Ausführungsbeispiele in Fällen verwendet werden, dass es zu Verletzungen von Grenzwertbedingungen kommen kann, dass es zur Konkurrenzsituationen auf Threadebene kommen kann, oder in ähnlichen Fällen. Im Fall von Konkurrenzsituationen auf Threadebene kann ein Thread auf denselben Speicherplatz schreiben, auf den gerade ein anderer parallel ausgeführter Thread zugreift, sodass der zweite Thread falsch ausgeführt werden kann. Mittels der Mechanismen gemäß den Ausführungsbeispielen kann der Transaktionsmonitor ermitteln, ob solche Konkurrenzsituationen eintreten oder wahrscheinlich eintreten können, und unter Verwendung der oben beschriebenen Mechanismen einen Thread zugunsten eines anderen abbrechen oder annullieren. Das heißt, die auf einem Thread ausgeführte aggressiv kompilierte Codeversion kann abgebrochen oder annulliert werden, sodass eine konservativ kompilierte Codeversion auf eher serielle Weise ausgeführt wird und die Konkurrenzsituation vermeidet.
Zu beachten ist, dass die Ausführungsbeispiele zwar in Bezug auf die Verwendung in einem Transaktionsverarbeitungssystem beschrieben werden, aber nicht darauf beschränkt sind. Vielmehr können die Mechanismen gemäß den Ausführungsbeispielen in jedem System realisiert werden, das sich einer aggressiven Spekulation bedient und bei dem eine Benachrichtigung ausgegeben wird, wenn die Spekulation fehlschlägt, sodass die Änderungen zurückgenommen oder verworfen werden können.
Gemäß den obigen Ausführungen sollte klar sein, dass die Ausführungsbeispiele die Form einer vollständigen Hardware-Ausführungsform, einer vollständigen Software-Ausführungsform oder einer Ausführungsform annehmen können, die sowohl Hardware- als auch Softwareelemente enthält. Gemäß einer beispielhaften Ausführungsform werden die Mechanismen der Ausführungsbeispiele in einem Software- oder Programmcode realisiert, der im Sinne einer nicht abschließenden Aufzählung Firmware, residente Software, Mikrocode usw. beinhaltet.
Ein Datenverarbeitungssystem, das zum Speichern und/oder Ausführen von Programmcode geeignet ist, beinhaltet mindestens einen Prozessor, der direkt oder indirekt über einen Systembus mit Speicherelementen verbunden ist. Die Speicherelemente können einen Arbeitsspeicher, der unmittelbar während der Ausführung des Programmcodes verwendet wird, einen Massenspeicher und Cachespeicher beinhalten, die zur zwischenzeitlichen Speicherung mindestens eines Programmcodes dienen, damit der Code während der Ausführung seltener vom Massenspeicher abgerufen werden muss.
Eingabe-/Ausgabe- oder E/A-Einheiten (darunter im Sinne einer nicht abschließenden Aufzählung Tastaturen, Bildschirme, Zeigeeinheiten usw.) können entweder direkt oder indirekt über E/A-Steuereinheiten mit dem System verbunden sein. Mit dem System können auch Netzadapter verbunden sein, damit das Datenverarbeitungssystem mit anderen Datenverarbeitungssystemen oder fernen Druckern oder Speichereinheiten oder öffentlichen Netzen verbunden werden kann. Modems, Kabelmodems und Ethernet-Karten stellen lediglich eine Auswahl der gegenwärtig verfügbaren Typen von Netzadaptern dar.
Die Beschreibung der vorliegenden Erfindung dient nur zur Veranschaulichung und Beschreibung und erhebt nicht den Anspruch der Vollständigkeit oder der Beschränkung der Erfindung in der dargelegten Form. Dem Fachmann sind viele Änderungen und Varianten offensichtlich. Die Ausführungsform wurde ausgewählt und beschrieben, um die Grundgedanken der Erfindung und deren praktische Anwendung bestmöglich zu erläutern und anderen Fachleuten das Verständnis der Erfindung für diverse Ausführungsformen mit diversen Änderungen zu ermöglichen, die für die jeweils vorgesehene Anwendung geeignet sind.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2009/023254 [0060]

Zitierte Nicht-Patentliteratur

Herlihy und Moss in dem Artikel „Transactional Memory: Architectural Support for Lock-Free Data Structures”, Proceedings of the 20th Annual International Symposium an Computer Architecture, Mai 1993, S. 289 bis 300 [0030]
Bobba et al. jedoch in dem Artikel „Performance Pathologies in Hardware Transactional Memory”, ISCA '07, 9. bis 13. Juni 2007 [0030]

Claims

Verfahren in einem Datenverarbeitungssystem (450) zum Ausführen eines ausführbaren Codes (415), wobei das Verfahren die folgenden Schritte umfasst: Empfangen eines ausführbaren Codes (415) mit einem Teil eines Codes, für den eine aggressiv kompilierte Codeversion (420) und eine konservativ kompilierte Codeversion (430) des Teils des Codes (415) bereitgestellt werden; Ausführen (610) der aggressiv kompilierten Codeversion (420) des Teils des Codes in einem Prozessor (206) des Datenverarbeitungssystems (450); Ermitteln (620), ob während der Ausführung der aggressiv kompilierten Codeversion (420) eine Ausnahmebedingung auftritt; Annullieren (630) der Änderungen an einem Zustand des Teils des Codes (415) als Reaktion auf eine Ermittlung, dass eine Ausnahmebedingung auftritt (620); und Ausführen (660, 780) der konservativ kompilierten Codeversion (430) in dem Prozessor (206) des Datenverarbeitungssystems (450) als Reaktion auf das Annullieren der Änderungen an dem Zustand des Teils des Codes (415).
Verfahren nach Anspruch 1, das ferner folgende Schritte umfasst: Erzeugen einer Vorhersage (720), ob die Ausführung der aggressiv kompilierten Codeversion (420) des ausführbaren Teils des Codes (415) wahrscheinlich zu einer Ausnahmebedingung führen kann; und als Reaktion auf die Vorhersage (720), die anzeigt, dass wahrscheinlich eine Ausnahmebedingung eintreten kann, wenn die aggressiv kompilierte Codeversion (420) ausgeführt wird, Ausführen der konservativ kompilierten Codeversion (430) in dem Prozessor (206) des Datenverarbeitungssystems (450).
Verfahren nach Anspruch 1, wobei die aggressiv kompilierte Codeversion (420) als eine einzelne Transaktion ausgeführt wird, die durch einen Transaktionsmonitor (460) des Datenverarbeitungssystems (450) überwacht wird.
Verfahren nach Anspruch 3, wobei: das Ermitteln (620), ob während der Ausführung der aggressiv kompilierten Codeversion (420) eine Ausnahmebedingung auftritt, das Ermitteln durch den Transaktionsmonitor (460) umfasst, ob die Transaktion, welche die aggressiv kompilierte Codeversion (420) umfasst, abgebrochen oder erfolgreich festgeschrieben wird, das Annullieren (630) der Änderungen an einem Zustand des Teils des Codes (415) als Reaktion auf eine Ermittlung, dass eine Ausnahmebedingung auftritt, das Annullieren der Transaktion umfasst, welche die aggressiv kompilierte Codeversion (420) umfasst, und die Ausnahmebedingung einen Abbruch der Transaktion verursacht.
Verfahren nach Anspruch 3, wobei das Ausführen der konservativ kompilierten Codeversion (430) in dem Prozessor (206) des Datenverarbeitungssystems (450) als Reaktion auf das Annullieren (630) der Änderungen an dem Zustand des ausführbaren Teils des Codes (415) folgende Schritte umfasst: Verwalten einer Datenstruktur (440) zum Zuordnen der aggressiv kompilierten Codeversion (420) zu der konservativ kompilierten Codeversion (430) in Verbindung mit dem Transaktionsmonitor (460); und Ausführen einer Suchoperation (650, 770) in der Datenstruktur (440) durch den Transaktionsmonitor (460) auf der Grundlage der aggressiv kompilierten Codeversion (420) als Reaktion auf den Abbruch der Transaktion, um einen Zeiger auf eine entsprechende konservativ kompilierte Codeversion (430) zu erhalten.
Verfahren nach Anspruch 3, die ferner folgende Schritte umfasst: Protokollieren (640, 760) von Transaktionen, die der abgebrochenen aggressiv kompilierten Codeversion (420) entsprechen, durch den Transaktionsmonitor (460) in einer Protokolldatenstruktur (470); Ausführen einer Vorhersageoperation (720) anhand der Protokolldatenstruktur (470), ob die Ausführung der aggressiv kompilierten Codeversion (420) wahrscheinlich zu einem Abbruch einer Transaktion führen kann, die mit der aggressiv kompilierten Codeversion (420) in Verbindung steht; und Auslösen (660, 780) der Ausführung der konservativ kompilierten Codeversion (430) anstelle der aggressiv kompilierten Codeversion (420) als Reaktion auf eine Vorhersage, dass die Ausführung der aggressiv kompilierten Codeversion (420) wahrscheinlich zu einem Abbruch der zugehörigen Transaktion führen kann.
Verfahren nach Anspruch 1, wobei es sich bei der aggressiv kompilierten Codeversion (420) um eine vektorisierte Version des Teils des Codes (415) handelt, die parallel ausgeführt wird, und wobei es sich bei der konservativ kompilierten Codeversion (430) um eine skalare Codeversion handelt, die seriell ausgeführt wird.
Computerprogrammprodukt, das ein computerlesbares Speichermedium (208, 226, 230) mit einem darin gespeicherten computerlesbaren Programm umfasst, wobei das computerlesbare Programm in einem Datenverarbeitungssystem (450) ausgeführt wird und das Datenverarbeitungssystem (450) zu Folgendem veranlasst: Empfangen eines ausführbaren Codes (415) mit einem Teil eines Codes, für den eine aggressiv kompilierte Codeversion (420) und eine aggressiv kompilierte Codeversion (430) des Teils des Codes (415) bereitgestellt werden; Ausführen (610) der aggressiv kompilierten Codeversion (420) des Teils des Codes in einem Prozessor (206) des Datenverarbeitungssystems (450); Ermitteln (620), ob während der Ausführung der aggressiv kompilierten Codeversion (420) eine Ausnahmebedingung auftritt; Annullieren (630) der Änderungen an einem Zustand des Teils des Codes (415) als Reaktion auf eine Ermittlung, dass eine Ausnahmebedingung auftritt (620); und Ausführen (660, 780) der konservativ kompilierten Codeversion (430) in dem Prozessor (206) des Datenverarbeitungssystems (450) als Reaktion auf das Annullieren der Änderungen an dem Zustand des Teils des Codes (415).
Computerprogrammprodukt nach Anspruch 8, wobei das computerlesbare Programm ferner das Datenverarbeitungssystem veranlasst: eine Vorhersage zu erzeugen (720), ob die aggressiv kompilierte Codeversion (420) des ausführbaren Teils des Codes (415) wahrscheinlich zum Auftreten einer Ausnahmebedingung führen kann; und die konservativ kompilierte Codeversion (430) in dem Prozessor (206) des Datenverarbeitungssystems (450) auszuführen, als Reaktion auf die Vorhersage (720), die anzeigt, dass wahrscheinlich eine Ausnahmebedingung auftreten kann, wenn die aggressiv kompilierte Codeversion (420) ausgeführt wird.
Computerprogrammprodukt nach Anspruch 8, wobei die aggressiv kompilierte Codeversion (420) als eine einzelne Transaktion ausgeführt wird, die durch einen Transaktionsmonitor (460) des Datenverarbeitungssystems (450) überwacht wird.
Computerprogrammprodukt nach Anspruch 10, wobei: das Ermitteln (620), ob während der Ausführung der aggressiv kompilierten Codeversion (420) eine Ausnahmebedingung auftritt, das Ermitteln durch den Transaktionsmonitor (460) umfasst, ob die Transaktion, welche die aggressiv kompilierte Codeversion (420) umfasst, abgebrochen oder erfolgreich festgeschrieben wird, das Annullieren (630) der Änderungen an einem Zustand des Teils des Codes (415) als Reaktion auf eine Ermittlung, dass eine Ausnahmebedingung auftritt, das Annullieren der Transaktion umfasst, welche die aggressiv kompilierte Codeversion (420) umfasst, und die Ausnahmebedingung einen Abbruch der Transaktion verursacht.
Computerprogrammprodukt nach Anspruch 10, wobei das computerlesbare Programm das Datenverarbeitungssystem (450) veranlasst, die konservativ kompilierte Codeversion (430) als Reaktion auf das Annullieren (630) der Änderungen an dem Zustand des ausführbaren Teils des Codes (415) in dem Prozessor (206) des Datenverarbeitungssystems (450) auszuführen durch: Verwalten einer Datenstruktur (440) in Verbindung mit dem Transaktionsmonitor (460) zum Zuordnen der aggressiv kompilierten Codeversion (420) zu der konservativ kompilierten Codeversion (430); und Ausführen einer Suchoperation (650, 770) in der Datenstruktur (440) durch den Transaktionsmonitor (460) auf der Grundlage der aggressiv kompilierten Codeversion (420) als Reaktion auf das Abbrechen der Transaktion, um einen Zeiger auf eine entsprechende konservativ kompilierte Codeversion (430) zu erhalten.
Computerprogrammprodukt nach Anspruch 10, wobei das computerlesbare Programm das Datenverarbeitungssystem ferner veranlasst: Transaktionen, die der abgebrochenen aggressiv kompilierten Codeversion (420) entsprechen, durch den Transaktionsmonitor (460) in einer Protokolldatenstruktur (470) zu protokollieren (640, 760); eine Vorhersageoperation (720) auf der Grundlage der Protokolldatenstruktur (470) auszuführen, ob die Ausführung der aggressiv kompilierten Codeversion (420) wahrscheinlich zu einem Abbruch einer Transaktion führt, die mit der aggressiv kompilierten Codeversion (420) in Verbindung steht; und Auslösen (660, 780) der Ausführung der konservativ kompilierten Codeversion (430) anstelle der aggressiv kompilierten Codeversion (420) als Reaktion auf eine Vorhersage, dass die Ausführung der aggressiv kompilierten Codeversion (420) wahrscheinlich zu einem Abbruch der zugehörigen Transaktion führt.
Vorrichtung zum Ausführen einer prädikativen atomaren Commitoperation von Speicheroperationen in einen Speicher, wobei die Vorrichtung Folgendes umfasst: einen Prozessor (206); und einen mit dem Prozessor (206) verbundenen Speicher (208) wobei der Prozessor (206) so gestaltet ist, dass er: in dem Speicher (208) einen ausführbaren Code (415) empfängt, der einen Teil eines Codes aufweist, für den eine aggressiv kompilierte Codeversion (420) und eine konservativ kompilierte Codeversion (430) des Codes (415) bereitgestellt werden; die aggressiv kompilierte Codeversion (420) des Teils des Codes (415) ausführt (610); ermittelt (620), ob während der Ausführung der aggressiv kompilierten Codeversion (420) eine Ausnahmebedingung auftritt; Änderungen an einem Zustand des Teils des Codes (415) als Reaktion auf eine Ermittlung annulliert, dass eine Ausnahmebedingung auftritt (620); und die konservativ kompilierte Codeversion (430) als Reaktion auf das Annullieren der Änderungen an dem Zustand des Teils des Codes (415) ausführt (660, 780).
Vorrichtung nach Anspruch 14, wobei der Prozessor (206) ferner so gestaltet ist, dass er: eine Vorhersage (720) erstellt, ob die Ausführung der aggressiv kompilierten Codeversion (420) des ausführbaren Teils des Codes (415) wahrscheinlich zum Auftreten einer Ausnahmebedingung führt; und als Reaktion auf die Vorhersage (720), die anzeigt, das wahrscheinlich eine Ausnahmebedingung auftritt, wenn die aggressiv kompilierte Codeversion (420) ausgeführt wird, die konservativ kompilierte Codeversion (430) in dem Prozessor (206) des Datenverarbeitungssystems (450) ausführt.
Vorrichtung nach Anspruch 14, wobei die aggressiv kompilierte Codeversion (420) als eine einzelne Transaktion ausgeführt wird, die durch einen Transaktionsmonitor (460) überwacht wird.
Vorrichtung nach Anspruch 16, wobei: der Prozessor (206) ermittelt (620), ob während der Ausführung der aggressiv kompilierten Codeversion (420) eine Ausnahmebedingung auftritt, indem er durch den Transaktionsmonitor (460) ermittelt, ob die Transaktion, welche die aggressiv kompilierte Codeversion (420) umfasst, abgebrochen oder erfolgreich festgeschrieben wird, der Prozessor (206) die Änderungen an einem Zustand des Teils des Codes (415) als Reaktion auf eine Ermittlung annulliert, dass eine Ausnahmebedingung auftritt, indem er die Transaktion annulliert, welche die aggressiv kompilierte Codeversion (420) umfasst, und die Ausnahmebedingung einen Abbruch der Transaktion verursacht.
Vorrichtung nach Anspruch 16, wobei der Prozessor (206) als Reaktion auf das Annullieren (630) der Änderungen an dem Zustand des ausführbaren Teils des Codes (415) die konservativ kompilierte Codeversion (430) ausführt, durch: Verwalten einer Datenstruktur (440) zum Zuordnen der aggressiv kompilierten Codeversion (420) zu der konservativ kompilierten Codeversion (430) in Verbindung mit dem Transaktionsmonitor (460); und Ausführen einer Suchoperation (650, 770) in der Datenstruktur (440) durch den Transaktionsmonitor (460) auf der Grundlage der aggressiv kompilierten Codeversion (420) als Reaktion auf das Abbrechen der Transaktion, um einen Zeiger auf eine entsprechende konservativ kompilierte Codeversion (430) zu erhalten.
Vorrichtung nach Anspruch 16, wobei der Prozessor (206) ferner dazu eingerichtet ist: Transaktionen, die der abgebrochenen aggressiv kompilierten Codeversion (420) entsprechen, durch den Transaktionsmonitor (460) in einer Protokolldatenstruktur (470) zu protokollieren (640, 760); eine Vorhersageoperation (720) auf der Grundlage der Protokolldatenstruktur (470) auszuführen, ob die Ausführung der aggressiv kompilierten Codeversion (420) wahrscheinlich zu einem Abbruch einer Transaktion führen kann, die mit der aggressiv kompilierten Codeversion (420) in Verbindung steht; und die Ausführung der konservativ kompilierten Codeversion (430) anstelle der aggressiv kompilierten Codeversion (420) als Reaktion auf eine Vorhersage auszulösen (660, 780), dass die Ausführung der aggressiv kompilierten Codeversion (420) wahrscheinlich zu einem Abbruch der zugehörigen Transaktion führen kann.
Vorrichtung nach Anspruch 14, wobei es sich bei der aggressiv kompilierten Codeversion (420) um eine vektorisierte Version des Teils des Codes (415) handelt, die parallel ausgeführt wird, und wobei es sich bei der konservativ kompilierten Codeversion (430) um eine skalare Codeversion handelt, die seriell ausgeführt wird.