DE60130840T2 - Vorrichtung und Verfahren zur Katalogisierung von symbolischen Daten zur Verwendung bei der Leistungsanalyse von Computerprogrammen - Google Patents

Vorrichtung und Verfahren zur Katalogisierung von symbolischen Daten zur Verwendung bei der Leistungsanalyse von Computerprogrammen Download PDF

Info

Publication number
DE60130840T2
DE60130840T2 DE60130840T DE60130840T DE60130840T2 DE 60130840 T2 DE60130840 T2 DE 60130840T2 DE 60130840 T DE60130840 T DE 60130840T DE 60130840 T DE60130840 T DE 60130840T DE 60130840 T2 DE60130840 T2 DE 60130840T2
Authority
DE
Germany
Prior art keywords
trace
data
module
file
symbolic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60130840T
Other languages
English (en)
Other versions
DE60130840D1 (de
Inventor
Riaz Y. Winchester Hussain
Chester Charles Winchester John
Frank Eliot Winchester Levine
Christopher Michael Winchester Richardson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Application granted granted Critical
Publication of DE60130840D1 publication Critical patent/DE60130840D1/de
Publication of DE60130840T2 publication Critical patent/DE60130840T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/323—Visualisation of programs or trace data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/835—Timestamp

Description

  • Technischer Bereich der Erfindung
  • Die vorliegende Erfindung betrifft eine Vorrichtung und ein Verfahren zum Katalogisieren von symbolischen Daten zur Verwendung bei der Leistungsanalyse von Computerprogrammen.
  • Hintergrund der Erfindung
  • Bei der Analyse und der Verbesserung der Leistungsfähigkeit eines Datenverarbeitungssystems und von Anwendungen, die in dem Datenverarbeitungssystem ausgeführt werden, ist es nützlich zu wissen, welche Softwaremodule in einem Datenverarbeitungssystem Systemressourcen verwenden. Eine leistungsfähige Verwaltung und die Verbesserung von Datenverarbeitungssystemen erfordern die Kenntnis darüber, wie und wann verschiedene Systemressourcen verwendet werden. Leistungshilfsprogramme werden verwendet, um ein Datenverarbeitungssystem zu überwachen und zu prüfen, um die Inanspruchnahme von Ressourcen zu ermitteln, wenn verschiedene Softwareanwendungen in dem Datenverarbeitungssystem ausgeführt werden. Ein Leistungshilfsprogramm kann z. B. die am häufigsten ausgeführten Module und Anweisungen in einem Datenverarbeitungssystem kennzeichnen oder kann jene Module kennzeichnen, die den größten Speicherumfang zuweisen oder die meisten E/A-Anforderungen ausführen. Hardware- Leistungshilfsprogramme können in das System integriert sein oder zu einem späteren Zeitpunkt hinzugefügt werden.
  • Software-Leistungshilfsprogramme sind ebenfalls nützlich in Datenverarbeitungssystemen wie z. B. in Personal-Computer-Systemen, die typischerweise nicht viele oder gar keine integrierten Hardware-Leistungshilfsprogramme enthalten. Ein bekanntes Software-Leistungshilfsprogramm ist ein Ablaufverfolgungshilfsprogramm. Ein Ablaufverfolgungshilfsprogramm kann mehrere Techniken verwenden, um Ablaufverfolgungsdaten bereitzustellen, die Ausführungsabläufe für ein ausgeführtes Programm angeben. Eine Technik verfolgt bestimmte Sequenzen von Anweisungen, indem bestimmte Ereignisse bei ihrem Auftreten protokolliert werden, und wird als eine so genannte ereignisgestützte Selbstdarstellungstechnik bezeichnet. Ein Ablaufverfolgungshilfsprogramm kann z. B. jeden Eintritt in ein Modul, eine Unterroutine, ein Verfahren, eine Funktion oder eine Systemkomponente und jeden Austritt aus diesen protokollieren. Ein Ablaufverfolgungshilfsprogramm kann alternativ den Anforderer und den Speicherumfang, der für jede Speicherzuweisungsanforderung zugewiesen wird, protokollieren.
  • Typischerweise wird ein mit einem Zeitstempel versehener Datensatz, wobei "Zeit" als ein monoton ansteigendes Maß definiert ist, wie etwa die Anzahl von ausgeführten Anweisungen, für jedes derartige Ereignis erzeugt. Entsprechende Paare von Datensätzen, ähnlich wie Eintritt-Austritt-Datensätze, werden außerdem verwendet, um die Ausführung von willkürlichen Codesegmenten, den Beginn und das Ende von Eingaben/Ausgaben oder von Datenübertragungen und viele weitere Ereignisse, die von Interesse sind, zu verfolgen.
  • Um die Leistungsfähigkeit von Code, der durch verschiedene Computerfamilien erzeugt wird, zu verbessern, ist es häufig erforderlich festzustellen, wann durch den Prozessor beim Ausführen von Code Zeit verbraucht wird, wobei derartige Bemühungen in der Technik der Computerverarbeitung im Allgemeinen als das Lokalisieren von "Hochbelastungspunkten" (hot spots) bekannt sind. Im Idealfall wäre es erwünscht, derartige Hochbelastungspunkte in der Befehls- und/oder Quellezeile der Codeebene zu isolieren, um die Aufmerksamkeit auf Bereiche zu richten, die von Verbesserungen am Code am meisten profitieren könnten.
  • Eine weitere Technik der Ablaufverfolgung beinhaltet das periodische Abtasten von Ausführungsabläufen eines Programms, um bestimmte Stellen in dem Programm zu ausfindig zu machen, an denen das Programm scheinbar eine lange Zeit verbringt. Diese Technik beruht auf der Idee der periodischen Unterbrechung der Anwendung oder der Ausführung des Datenverarbeitungssystems in regelmäßigen Intervallen, der so genannten abtastungsgestützten Selbstdarstellung. Bei jeder Unterbrechung werden Daten für eine vorgegebene Zeitspanne oder für eine vorgegebene Anzahl von Ereignissen, die von Interesse sind, aufgezeichnet. Der Programmzähler des gegenwärtig ausgeführten Programmsegments (thread) kann z. B. während der Intervalle aufgezeichnet werden. Diese Werte können in Bezug auf eine Belastungsdarstellung und Symbolinformationen für das Datenverarbeitungssystem zum Analysezeitpunkt untersucht werden, wobei aus dieser Analyse ein Profil über die verbrachte Zeit erhalten werden kann.
  • Das Isolieren derartiger Hochbelastungspunkte auf der Befehlsebene kann z. B. wesentliche Bereiche eines nicht zufrieden stellenden Codes kennzeichnen, wodurch die Leistungsanalytiker unterstützt werden, ihre Aufmerksamkeit auf die Verbesserung der Leistung des "wichtigen" Codes zu konzentrieren. Dies kann außerdem Verfassern von Kompilierprogrammen helfen, ihre Aufmerksamkeit auf die Verbesserung der Wirksamkeit des erzeugten Codes zu konzentrieren. Dies gilt insbesondere für "Jitted"-Code (der später in dieser Anmeldung beschrieben wird). Eine weitere potentielle Verwendung der Einzelheiten der Befehlsebene besteht in der Anleitung der Entwickler zukünftiger Systeme. Diese Entwickler verwenden Selbstdarstellungshilfsprogramme, um kennzeichnende Codefolgen und/oder einzelne Befehle zu finden, die eine Optimierung für die verfügbare Software bei einem vorgegebenen Typ der Hardware erfordern.
  • Anwendungen von Datenverarbeitungssystemen sind typischerweise aus symbolischen Daten aufgebaut und können sogar an Client-Einheiten ausgeliefert werden, während symbolische Daten immer noch in den Modulen vorhanden sind. Symbolische Daten sind z. B. alphanumerische Darstellungen von Modulnamen, Unterroutinennamen, Funktionsnamen, Variablennamen der Anwendung und dergleichen.
  • Die Anwendung besteht aus Modulen, die als Quellencode in einer symbolischen Sprache wie FORTRAN oder C++ geschrieben sind und dann durch Kompilieren des Quellencodes in einen Maschinencode umgesetzt werden. Der Maschinencode ist die prozessorspezifische Sprache des Computers. Damit ein Programm ablaufen kann, muss es dem Computer als binär codierte Maschinenbefehle präsentiert werden, die für dieses CPU-Modell oder diese CPU-Familie spezifisch sind.
  • Die Maschinensprache sagt dem Computer, was zu tun ist und wo es zu tun ist. Wenn ein Programmierer schreibt: total = total + subtotal, wird diese Anweisung in einen Maschinenbefehl umgesetzt, der dem Computer sagt, die Inhalte von zwei Speicherbereichen zu addieren, in denen TOTAL und SUBTOTAL gespeichert sind.
  • Da die Anwendung als Maschinencode ausgeführt wird, werden Leistungsablaufverfolgungsdaten des ausgeführten Maschinencodes, die durch die Ablaufverfolgungshilfsprogramme erzeugt werden, d. h. Prozesskennungen, Adressen und dergleichen, in Form des Maschinencodes bereitgestellt. Deswegen kann es für einen Benutzer der Ablaufverfolgungshilfsprogramme schwierig sein, die Module, Befehle und dergleichen aus den reinen Maschinencodedarstellungen in den Leistungsablaufverfolgungsdaten zu identifizieren. Deswegen müssen die Ablaufverfolgungsdaten mit symbolischen Daten korreliert werden, um Ablaufverfolgungsdaten zu erzeugen, die durch einen Benutzer der Ablaufverfolgungshilfsprogramme leicht interpretiert werden können.
  • Die symbolischen Daten, mit denen die Ablaufverfolgungsdaten korreliert werden müssen, können über eine Vielzahl von Dateien verteilt sein. Die symbolischen Daten können z. B. in Fehlersuchdateien, Abbildungsdateien, anderen Versionen der Anwendung und dergleichen vorhanden sein. Um die symbolischen Daten mit den Leistungsablaufverfolgungsdaten zu korrelieren, muss das Leistungshilfsprogramm in den bekannten Systemen von Leistungshilfsprogrammen die Speicherorte von einer oder mehreren der Quellen des symbolischen Daten kennen und ein komplexes Verfahren aufweisen, damit es Redundanzen in den symbolischen Daten behandeln kann.
  • Außerdem wird eine derartige Korrelation typischerweise während einer Nachverarbeitung der Leistungsablaufverfolgungsdaten ausgeführt. Dadurch ist ein zusätzlicher Schritt erforderlich, um die Leistungsablaufverfolgungsdaten in symbolische Darstellungen umzusetzen, die für einen Leistungsanalytiker verständlich sind.
  • Die Umsetzung von Leistungsablaufverfolgungsdaten in symbolische Darstellungen wird zu einem Zeitpunkt ausgeführt, der von dem Zeitpunkt entfernt ist, an dem die Leistungsablaufverfolgung ausgeführt wird. Folglich können die symbolischen Daten mit der bestimmten Version des Computerprogramms, das während der Ablaufverfolgung ausgeführt wird, möglicherweise nicht konsistent sein. Der Grund dafür kann in der Tatsache liegen, dass z. B. eine neuere Version der Anwendung während der Ablaufverfolgung ausgeführt wird und die symbolischen Daten einer älteren Version der Anwendung entsprechen.
  • Dies kann insbesondere für Anwendungen gelten, deren symbolische Daten am Ort eines Lieferanten gespeichert werden, während der Maschinencode an eine Vielzahl von Clients verteilt ist. In diesem Fall kann der Lieferant weiterhin die symbolischen Daten aktualisieren, d. h. neue Versionen der Anwendung erzeugen, er kann es jedoch versäumen, die neueste Version der Anwendung für alle Clients bereitzustellen. Wenn bei diesem Szenario eine Leistungsablaufverfolgung ausgeführt werden soll, können die symbolischen Daten, die durch den Lieferanten gespeichert werden, nicht von der gleichen Version stammen wie der Maschinencode, an dem die Leistungsablaufverfolgung ausgeführt wird.
  • In der Patentanmeldung EP 0 767 430 wird ein System zur Softwareanalyse zum Aufnehmen von Kennzeichen beschrieben, die durch Kennzeichenanweisungen im instrumentierten Quellencode erzeugt werden. Das System zur Softwareanalyse enthält einen Messgeber, der den Adressen- und Datenbus des Zielsystems überwacht. Wenn im Zielsystem eine Kennzeichenanweisung ausgeführt wird, wird ein Kennzeichen an einen vorgegebenen Ort im Adressenraum des Zielsystems geschrieben. Das Kennzeichen enthält einen Kennzeichenwert, der eine Angabe des Orts der Kennzeichenanweisung, die das Kennzeichen erzeugt, im Quellencode ist. Durch Überwachen der vorgegebenen Adresse kann der Messgeber Kennzeichen aufnehmen, wenn sie auf den Datenbus des Zielsystems geschrieben werden. Durch eine geeignete Instrumentierung des Quellencodes kann die Softwareanalyse eine Vielzahl von Analysefunktionen im Wesentlichen in Echtzeit ausführen, einschließlich Codeabdeckung, Funktions- und Task-Ausführungszeiten, Speicherzuweisung, Anrufpaare und Programmablaufverfolgung.
  • Es wäre daher vorteilhaft, einen Mechanismus zu haben, durch den symbolische Daten für eine Vielzahl von Quellen zu einer einzigen Quelle symbolischer Daten für eine Anwendung, die einer Leistungsanalyse unterzogen wird und an der eine Ablaufverfolgung erfolgt, verknüpft werden können.
  • Es wäre des Weiteren vorteilhaft, einen Mechanismus zu haben, um die symbolischen Daten zu prüfen, ob sie der gleichen Version der Anwendung, die einer Leistungsanalyse unterzogen wird und an der eine Ablaufverfolgung erfolgt, entsprechen. Darüber hinaus wäre es vorteilhaft, einen Mechanismus zur Überprüfung der symbolischen Daten zu haben, die der gleichen Version wie die jener Anwendung entsprechen, die einer Leistungsanalyse unterzogen wird und die gerade verfolgt wird. Es wäre außerdem vorteilhaft, einen Mechanismus zu haben, durch den die symbolische Zerlegung als eine integrierte Operation der Leistungsablaufverfolgung der Anwendung ausgeführt werden kann.
  • BESCHREIBUNG DER ERFINDUNG
  • Die vorliegende Erfindung stellt eine Vorrichtung und ein Verfahren zur Katalogisierung von symbolischen Daten zur Verwendung bei der Leistungsanalyse von Computerprogrammen bereit. Die vorliegende Erfindung stellt insbesondere eine Vorrichtung und ein Verfahren zum Speichern von symbolischen Daten für ausführbare Module bereit. Die symbolischen Daten werden verwendet, wenn eine Leistungsablaufverfolgung ausgeführt wird.
  • Die vorliegende Erfindung enthält einen Mechanismus, durch den eine Mischsymboldatei für ein Computerprogramm oder eine Anwendung, bei dem bzw. der Ablaufverfolgung ausgeführt wird, erzeugt wird. Die Mischsymboldatei enthält Daten, die bei der Ausführung einer symbolischen Zerlegung von Adressdaten in Ablaufverfolgungsdateien für jedes einzelne Modul nützlich sind.
  • Während der Nachverarbeitung der Ablaufverfolgungsdaten, die durch eine Leistungsablaufverfolgung eines Computerprogramms erzeugt werden, werden symbolische Daten, die in der Mischsymboldatei gespeichert sind, mit den Ablaufverfolgungsdaten, die in der Ablaufverfolgungsdatei gespeichert sind, verglichen. Die Nachverarbeitung erfolgt typischerweise kurz nach der Ablaufverfolgung oder zu einem späteren Zeitpunkt nach der Ablaufverfolgung des Computerprogramms.
  • Die Ablaufverfolgungsdaten enthalten Daten, die die Module kennzeichnen, die während der Ablaufverfolgung des Computerprogramms geladen sind. Diese Ablaufverfolgungsdaten und die Mischsymboldatei werden verwendet, um Berichte zu erzeugen. Die korrekten symbolischen Daten in der Mischsymboldatei für die geladenen Module werden anhand einer Anzahl von Bewertungskriterien gekennzeichnet. Alternativ werden die korrekten symbolischen Daten in der Mischsymboldatei für die Module, die bei der Ablaufverfolgung verwendet werden oder im Fall der Selbstdarstellung unterbrochen werden, anhand einer Anzahl von Bewertungskriterien gekennzeichnet.
  • Die korrekten symbolischen Daten für die erforderlichern Module können dann als eine indexierte Datenbank gespeichert werden, die z. B. durch Prozess- und Adressenkennungen indexiert ist. Die indexierte Datenbank symbolischer Daten kann als eine getrennte Datei oder als ein getrennter Abschnitt einer Ablaufverfolgungsdatei für die Computeranwendung gespeichert werden. Diese indexierte Datenbank kann dann verwendet werden, um Adressendaten in entsprechende symbolische Daten zu zerlegen, wenn die Ablaufverfolgungsinformationen zur Verwendung durch einen Benutzer, wie z. B. einen Leistungsanalytiker bereitgestellt werden.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Erfindung wird im Folgenden lediglich beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen beschrieben; es zeigen:
  • 1 einen beispielhaften Blockschaltplan eines verteilten Datenverarbeitungssystems gemäß der vorliegenden Erfindung;
  • 2A einen beispielhaften Blockschaltplan eines Datenverarbeitungssystems gemäß der vorliegenden Erfindung;
  • 2B einen beispielhaften Blockschaltplan eines Datenverarbeitungssystems gemäß der vorliegenden Erfindung;
  • 3A ein Blockschaubild, das die Beziehung von Softwarekomponenten in einem Computersystem veranschaulicht, in dem die vorliegende Erfindung realisiert werden kann;
  • 3B ein beispielhaftes Blockschaubild einer virtuellen Java-Maschine (Java Virtual Machine, JVM) gemäß der vorliegenden Erfindung;
  • 4 ein Blockschaubild, das Komponenten darstellt, die verwendet werden, um Prozesse in einem Datenverarbeitungssystem zu profilieren;
  • 5 eine Darstellung, die verschiedene Phasen der Profilierung der aktiven Prozesse in einem Betriebssystem aufzeigt;
  • 6 eine beispielhafte Darstellung, die eine zeitliche Abfolge von Ereignissen gemäß der vorliegenden Erfindung veranschaulicht;
  • 7 einen Ablaufplan, der einen beispielhaften Betrieb eines Ablaufverfolgungsprogramms zum Erzeugen von Ablaufverfolgungsdatensätzen aus Prozessen, die in einem Datenverarbeitungssystem ausgeführt werden, darstellt;
  • 8 einen Ablaufplan, der einen beispielhaften Betrieb einer Ablaufverfolgungseinrichtung zur Behandlung von Systemunterbrechungen darstellt;
  • 9 eine beispielhafte Darstellung, die die Erzeugung einer Mischsymboldatei gemäß der vorliegenden Erfindung veranschaulicht;
  • 10A eine beispielhafte Darstellung, die die Organisation einer Mischsymboldatei gemäß der vorliegenden Erfindung veranschaulicht;
  • 10B eine beispielhafte Darstellung einer Mischsymboldatei;
  • 11 eine beispielhafte Darstellung von Leistungsablaufverfolgungsdaten, die als eine Ablaufverfolgungsdatei gespeichert oder im Ablaufverfolgungspuffer gespeichert werden können;
  • 12 eine beispielhafte Darstellung einer Modultabelleneintrag-Datei gemäß der vorliegenden Erfindung;
  • 13A eine beispielhafte Darstellung einer indexierten Datenbank gemäß der vorliegenden Erfindung;
  • 13B einen Ablaufplan, der einen beispielhaften Betrieb eines Nachprozessors zum Erzeugen einer indexierten Datenbank anhand der MTE-Daten und der Mischsymboldatei zusammenfasst;
  • 14 einen Ablaufplan, der einen beispielhaften Betrieb der vorliegenden Erfindung umreißt, wenn eine indexierte Datenbank mit symbolischen Daten erzeugt wird;
  • 15 einen Ablaufplan, der einen beispielhaften Betrieb der vorliegenden Erfindung umreißt, wenn eine indexierte Datenbank mit symbolischen Daten aus Leistungsablaufverfolgungsdaten, die in dem Ablaufverfolgungspuffer dynamisch gespeichert werden, erzeugt wird;
  • 16 einen Ablaufplan, der einen beispielhaft Betrieb der vorliegenden Erfindung umreißt, wenn die symbolischen Daten und Informationen der geladenen Module überprüft werden;
  • 17 einen Ablaufplan, der einen beispielhaften Betrieb der vorliegenden Erfindung umreißt, wenn der am besten übereinstimmende Moduleintrag aus der Mischsymboldatei erhalten wird; und
  • 18 einen Ablaufplan, der einen beispielhaften Betrieb der vorliegenden Erfindung umreißt, wenn eine Anzeige symbolischer Ablaufverfolgungsdaten erzeugt wird;
  • 19 eine beispielhafte Darstellung eines Abschnitts einer typischen Basic-Block-Datei (.bbf) für ein Computerprogramm;
  • 20 eine beispielhafte Darstellung eines Abschnitts einer .bbf-Datei für ein Computerprogramm gemäß der vorliegenden Erfindung; und
  • 21 einen Ablaufplan, der einen beispielhaften Betrieb einer weiteren Ausführungsform der vorliegenden Erfindung umreißt.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • In 1 ist eine bildliche Darstellung eines verteilten Datenverarbeitungssystems, in dem die vorliegende Erfindung realisiert werden kann, gezeigt. Das verteilte Datenverarbeitungssystem 100 ist ein Netzwerk aus Computern, in dem die vorliegende Erfindung realisiert werden kann. Das verteilte Datenverarbeitungssystem 100 enthält ein Netzwerk 102, bei dem es sich um das Medium handelt, das verwendet wird, um Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Computern, die in dem verteilten Datenverarbeitungssystem 100 miteinander verbunden sind, bereitzustellen. Das Netzwerk 102 kann ständige Verbindungen, wie etwa Drahtleitungskabel oder Lichtwellenleiterkabel, oder zeitweilige Verbindungen, die über Telefonverbindungen hergestellt werden, enthalten.
  • In dem dargestellten Beispiel ist ein Server 104 gemeinsam mit einer Speichereinheit 106 mit dem Netzwerk 102 verbunden. Außerdem sind Clients 108, 110 und 112 ebenfalls mit einem Netzwerk 102 verbunden. Diese Clients 108, 110 und 112 können z. B. Personal Computer oder Netzwerkcomputer sein. Für die Zwecke dieser Anmeldung ist ein Netzwerkcomputer ein beliebiger mit einem Netzwerk verbundener Computer, der ein Programm oder eine andere Anwendung von einem anderen Computer, der mit dem Netzwerk verbunden ist, empfängt. In dem dargestellten Beispiel stellt der Server 104 Daten wie etwa Boot-Dateien, Betriebssystem-Speicherabbilder und Anwendungen für Clients 108 bis 112 bereit. Die Clients 108, 110 und 112 sind Clients des Servers 104. Das verteilte Datenverarbeitungssystem 100 kann zusätzliche Server, Clients und weitere Einheiten, die nicht gezeigt sind, enthalten. In dem dargestellten Beispiel ist das verteilte Datenverarbeitungssystem 100 das Internet, wobei das Netzwerk 102 eine weltweite Sammlung von Netzwerken und Gateways darstellt, die die TCP/IP-Protokollgruppe für einen gegenseitigen Datenaustausch verwenden. Das Herz des Internet ist eine Haupttrasse aus schnellen Datenübertragungsleitungen zwischen Hauptknoten oder Hostcomputern, die Tausende von kommerziellen, staatlichen, Bildungs- und anderen Computersystemen enthalten, die Daten und Nachrichten leiten. Das verteilte Datenverarbeitungssystem 100 kann natürlich auch in Form von mehreren unterschiedlichen Typen von Netzwerken realisiert sein, z. B. ein Intranet oder ein lokales Netzwerk.
  • In 2A ist ein Blockschaltplan eines Datenverarbeitungssystems, das als ein Server, wie z. B. der Server 104 von 1 realisiert ist, gemäß der vorliegenden Erfindung dargestellt. Das Datenverarbeitungssystem 200 kann ein symmetrisches Mikroprozessorsystem (SMP) sein, das eine Vielzahl von Prozessoren 202 und 204 enthält, die mit dem Systembus 206 verbunden sind. Alternativ kann ein Einzelprozessorsystem verwendet werden. Eine Anordnung Speichersteuereinheit/Cachespeicher 208, die eine Schnittstelle zu einem lokalen Speicher 209 bereitstellt, ist außerdem mit dem Systembus 206 verbunden. Eine E/A-Busbrücke 210 ist mit dem Systembus 206 verbunden und stellt eine Schnittstelle zum E/A-Bus 212 bereit. Die Anordnung Speichersteuereinheit/Cachespeicher 208 und die E/A-Busbrücke 210 können in der dargestellten Weise integriert sein.
  • Eine Busbrücke 214 zur Verbindung peripherer Komponenten (PCI-Busbrücke), die mit dem E/A-Bus 210 verbunden ist, stellt eine Schnittstelle zum lokalen PCI-Bus 216 bereit. Ein Modem 218 kann mit dem lokalen PCI-Bus 216 verbunden sein. Typische PCI-Bus-Realisierungen unterstützen vier PCI-Erweiterungssteckplätze oder Zusatzverbinder. Datenübertragungsverbindungen zu Netzwerkcomputern 109 bis 212 in 1 können über den Modem 218 und einen Netzwerkadapter 220, der mit Empfänger lokalen PCI-Bus 216 verbunden ist, über Zusatzplatten bereitgestellt werden.
  • Zusätzliche PCI-Busbrücken 222 und 224 schaffen Schnittstellen für zusätzliche PCI-Busse 226 und 228, von denen zusätzliche Modems oder Netzwerkadapter unterstützt werden können. Auf diese Weise ermöglicht der Server 200 Verbindungen zu mehreren Netzwerkcomputern. Ein im Speicher abgebildeter Grafikadapter 230 und eine Festplatte 232 können außerdem in der dargestellten Weise entweder direkt oder indirekt mit dem E/A-Bus 212 verbunden sind.
  • Ein Fachmann wird erkennen, dass die in 2A gezeigten Hardware unterschiedlich sein kann. Es können z. B. andere periphere Einheiten wie etwa optische Plattenlaufwerke und dergleichen zusätzlich oder anstelle der dargestellten Hardware verwendet werden. Das dargestellte Beispiel soll keine Architektureinschränkungen in Bezug auf die vorliegende Erfindung beinhalten.
  • Das in 2A dargestellte Datenverarbeitungssystem kann z. B. ein System IBM RISC/System 6000 sein, ein Produkt der International Business Machines, das das Betriebssystem Advanced Interactive Executive (AIX) verwendet.
  • In 2B ist ein Blockschaltplan eines Datenverarbeitungssystems, in dem die vorliegende Erfindung realisiert werden kann, veranschaulicht. Das Datenverarbeitungssystem 250 ist ein Beispiel eines Client-Computers. Das Datenverarbeitungssystem 250 verwendet eine Architektur des lokalen Busses zur Verbindung peripherer Komponenten (PCI). Obwohl in dem dargestellten Beispiel ein PCI-Bus verwendet wird, können weitere Busarchitekturen wie Micro Channel und ISA verwendet werden. Der Prozessor 252 und der Hauptspeicher 254 sind über die PCI-Brücke 258 mit dem PCI-Lokalbus 256 verbunden. Die PCI-Brücke 258 kann außerdem eine integrierte Speichersteuereinheit und einen Cache-Speicher für den Prozessor 252 enthalten. Zusätzliche Verbindungen mit dem PCI-Lokalbus 256 können durch Zwischenverbindungen durch direkte Komponenten oder durch Zusatzplatinen hergestellt werden. In dem dargestellten Beispiel sind Lokalnetz-Adapter (LAN-Adapter) 260, SCSI-Hostbusadapter 262 und eine Erweiterungsbusschnittstelle 264 durch eine Verbindung durch direkte Komponenten mit dem PCI- Lokalbus 256 verbunden. Dagegen sind der Audioadapter 266, der Grafikadapter 268 und der Audio/Videoadapter (A/V) 269 durch Zusatzplatinen, die in Erweiterungssteckplätze eingesetzt sind, mit dem PCI-Lokalbus 266 verbunden. Die Erweiterungsbusschnittstelle 264 stellt eine Verbindung für einen Tastatur- und Mausadapter 270, einen Modem 272 und einen zusätzlichen Speicher 274 bereit. Der SCSI-Hostbusadapter 262 stellt in dem dargestellten Beispiel eine Verbindung für ein Festplattenlaufwerk 276, ein Bandlaufwerk 278 und einen CD-ROM 280 bereit. Typische Realisierungen des PCI-Lokalbusses unterstützen drei oder vier PCI-Erweiterungssteckplätze oder Zusatzverbinder.
  • Ein Betriebssystem läuft im Prozessor 252 und wird verwendet, um eine Steuerung verschiedener Komponenten in dem Datenverarbeitungssystem 250 von 2B zu koordinieren und bereitzustellen. Das Betriebssystem kann ein handelsübliches Betriebssystem wie JavaOS For Business oder OS/2 sein, die von International Business Machines Corporation zur Verfügung stehen. JavaOS wird von einem Server an einem Netzwerk zu einem Netzwerk-Client geladen und unterstützt Java-Programme und Applets. Eine Reihe von Charakteristiken des JavaOS, die für das Ausführen von Ablaufverfolgungen mit Stapelregisterabwicklungen vorteilhaft sind, wie später beschrieben wird, bestehen darin, dass JavaOS keinen seitenorientierten oder virtuellen Speicher unterstützt. Ein objektorientiertes Programmiersystem wie Java kann in Verbindung mit dem Betriebssystem laufen und kann Aufrufe zum Betriebssystem von Java-Programmen oder Anwendungen, die im Datenverarbeitungssystem 250 ausgeführt werden, ausführen. Befehle für das Betriebssystem, das objektorientierte Betriebssystem und Anwendungen oder Programme befinden sich in Speichereinheiten, wie etwa das Festplattenlaufwerk 276, und können für eine Ausführung durch den Prozessor 252 in den Hauptspeicher 254 geladen werden. Häufig fehlen Festplattenlaufwerke, und der Speicher ist eingeschränkt, wenn ein Datenverarbeitungssystem 250 als ein Netzwerk-Client verwendet wird.
  • Dem Fachmann ist klar, dass die Hardware von 2B in Abhängigkeit von der Realisierungsmöglichkeit unterschiedlich sein kann. Es können z. B. andere periphere Einheiten wie etwa optische Plattenlaufwerke und dergleichen, zusätzlich oder anstelle der in 2B gezeigten Hardware verwendet werden. Das dargestellte Beispiel soll nicht zu Architektureinschränkungen in Bezug auf vorliegende Erfindung führen. Die Prozesse der vorliegenden Erfindung können z. B. bei einem Mehrprozessor-Datenverarbeitungssystem angewendet werden.
  • Die vorliegende Erfindung stellt ein Verfahren und ein System zum Verarbeiten von Leistungsablaufverfolgungsdaten von Softwareanwendungen bereit. Obwohl die vorliegende Erfindung auf einer Vielzahl von Computerplattformen und Betriebssystemen betrieben werden kann, kann sie außerdem in einer interpretativen Umgebung wie etwa REXX-, Smalltalk- oder Java-Laufzeit-Umgebung und dergleichen arbeiten. Die vorliegende Erfindung kann z. B. in Verbindung mit einer virtuellen Java-Maschine (JVM) noch innerhalb der Grenzen von JVM, die durch Java-Standarddefinitionen definiert sind, betrieben werden. Um einen Kontext für die vorliegende Erfindung in Bezug auf eine beispielhafte interpretative Umgebung zu schaffen, werden an dieser Stelle Abschnitte des Betriebs einer JVM gemäß Java-Spezifikationen beschrieben.
  • In Fig. 3A veranschaulicht ein Blockschaubild die Beziehung von Softwarekomponenten, die in einem Computersystem betrieben werden, in dem die vorliegende Erfindung realisiert werden kann. Ein Java-gestütztes System 300 enthält ein plattformspezifisches Betriebssystem 302, das Hardware und Systemunterstützung für Software bereitstellt, die auf einer speziellen Hardwareplattform ausgeführt wird. Die JVM 304 ist eine Softwareanwendung, die in Verbindung mit dem Betriebssystem ausgeführt werden kann. Die JVM 304 stellt eine Java-Laufzeit-Umgebung dar, die eine Java-Anwendung oder ein Java-Applet 306, das ein Programm, ein Servlet oder eine Softwarekomponente ist, die in der Programmiersprache Java geschrieben ist, ausführen kann. Das Computersystem, in dem die JVM 304 betrieben wird, kann dem Datenverarbeitungssystem 200 oder dem Computer 100, die oben beschrieben wurden, ähnlich sein. Eine JVM 304 kann jedoch in einer speziellen Hardware auf einem so genannten Java-Chip, Java-auf-Silizium oder Java-Prozessor mit einem eingebetteten Pico-Java-Kern realisiert sein. Im Zentrum einer Java-Laufzeit-Umgebung befindet sich die JVM, die alle Aspekte der Java-Umgebung, einschließlich ihrer Architektur, Sicherheitsmerkmale, der netzwerkübergreifenden Mobilität und der Plattformunabhängigkeit unterstützt.
  • Die JVM ist ein virtueller Computer, d. h. ein Computer, der abstrakt spezifiziert ist. Die Spezifikation definiert bestimmte Merkmale, die bei jeder JVM in einem Bereich von Gestaltungsmerkmalen realisiert sein müssen, die von der Plattform abhängen können, auf der die JVM betrieben werden soll. Alle JVMs müssen z. B. Java-Bytecodes ausführen und können einen Bereich von Techniken verwenden, um die Befehle auszuführen, die durch die Bytecodes dargestellt werden. Eine JVM kann vollständig in Software oder teilweise in Hardware realisiert sein. Diese Flexibilität ermöglicht, dass unterschiedliche JVMs für Großcomputer und PDAs entworfen werden.
  • Die JVM ist die Bezeichnung einer Komponente des virtuellen Computers, die Java-Programme tatsächlich ausführt. Java-Programme werden nicht direkt durch den Zentralprozessor, sondern durch die JVM ausgeführt, die selbst ein Teil der Software ist, die auf dem Prozessor läuft. Die JVM ermöglicht, dass Java-Programme auf einer anderen Plattform ausgeführt werden als lediglich die eine Plattform, für die der Code kompiliert wurde. Java-Programme werden für die JVM kompiliert. Auf diese Weise kann Java Anwendungen für viele Typen von Datenverarbeitungssystemen unterstützen, die eine Vielfalt von zentralen Verarbeitungseinheiten und Betriebssystem-Architekturen enthalten können. Damit Java-Anwendungen auf unterschiedlichen Typen von Datenverarbeitungssystemen ausgeführt werden können, erzeugt ein Kompilierer typischerweise ein architekturneutrales Dateiformat, wobei der kompilierte Code auf vielen Prozessoren ausführbar ist, vorausgesetzt, das Java-Laufzeit-System ist vorhanden.
  • Der Java-Kompilierer erzeugt Bytecode-Befehle, die für eine bestimmte Computerarchitektur unspezifisch sind. Der Bytecode ist ein maschinenunabhängiger Code, der durch den Java-Kompilierer erzeugt und durch den Java-Interpreter ausgeführt wird. Ein Java-Interpreter ist Teil der JVM, die einen Bytecode oder Bytecodes abwechselnd decodiert und übersetzt. Diese Bytecode-Befehle sind so beschaffen, dass sie auf einem beliebigen Computer leicht übersetzt und in einfacher Weise laufend in prozessorspezifischen (native) Maschinencode übertragen werden können.
  • Eine JVM muss Klassendateien laden und in ihnen die Bytecodes ausführen. Die JVM enthält eine Klassenladeeinrichtung, die Klassendateien aus einer Anwendung und die Klassendateien von den Programmierschnittstellen des Java-Anwendung (APIs), die von der Anwendung benötigt werden, lädt. Die Ausführungsmaschine, die den Bytecode ausführt, kann sich bei Plattformen und Realisierungsformen unterscheiden.
  • Ein Typ der softwaregestützten Ausführungsmaschine ist ein „zeitoptimaler Kompilierer" (just-in-time compiler). Bei dieser Art der Ausführung werden die Bytecodes eines Verfahrens zum prozessorspezifischen Maschinencode kompiliert, wenn einige Typen von Kriterien zur "zeitoptimalen Ausführung" eines Verfahrens (jitting a method) erfüllt sind. Der prozessorspezifische Maschinencode für das Verfahren wird dann im Cachespeicher gespeichert und beim nächsten Aufruf des Verfahrens wieder verwendet. Die Ausführungsmaschine kann außerdem in Hardware realisiert und auf einem Chip eingebettet sein, so dass die Java-Bytecodes in der prozessorspezifischen Sprache ausgeführt werden. JVMs übersetzen gewöhnlich Bytecodes, JVMs können jedoch auch andere Techniken wie etwa zeitoptimales Kompilieren verwenden, um Bytecodes auszuführen.
  • Das Übersetzen von Code schafft einen zusätzlichen Vorteil. Anstelle der Instrumentierung des Java-Quellencodes kann der Interpreter instrumentiert werden. Ablaufverfolgungsdaten können über ausgewählte Ereignisse und Zeitgeber durch den instrumentierten Interpreter ohne Modifizieren des Quellencodes erzeugt werden. Die Instrumentierung der Leistungsablaufverfolgung wird später genauer erläutert.
  • Wenn eine Anwendung in einer JVM ausgeführt wird, die in Software auf einem plattformspezifischen Betriebssystem realisiert ist, kann eine Java-Anwendung mit dem Host-Betriebssystem durch das Aufrufen von prozessorspezifischen Verfahren in Wechselwirkung treten. Ein Java-Verfahren wird in der Java-Sprache geschrieben, zu Bytecodes kompiliert und in Klassendateien gespeichert. Ein prozessorspezifisches Verfahren wird in einer anderen Sprache geschrieben und zum prozessorspezifischen Maschinencode eines bestimmten Prozessors kompiliert. Prozessorspezifische Verfahren werden in dynamisch verknüpften Bibliotheken gespeichert, deren genaue Form plattformspezifisch ist.
  • In 3B ist ein Blockschaubild einer JVM in Übereinstimmung mit einer beispielhaften Darstellung der vorliegenden Erfindung dargestellt. Die JVM 350 enthält ein Klassenladeeinrichtungs-Teilsystem 352, bei dem es sich um einen Mechanismus zum Laden von Typen handelt wie etwa Klassen und Schnittstellen, denen vollständig qualifizierte Bezeichnungen gegeben wurden. Die JVM 350 enthält außerdem Laufzeit-Datenbereiche 354, eine Ausführungsmaschine 356, eine Schnittstelle 358 für prozessorspezifische Verfahren und eine Speicherverwaltung 374. Die Ausführungsmaschine 356 ist ein Mechanismus zum Ausführen von Befehlen, die in den Verfahren der Klassen enthalten sind, die durch das Klassenladeeinrichtungs-Teilsystem 352 geladen werden. Die Ausführungsmaschine 356 kann z. B. ein Java-Interpreter 362 oder ein zeitoptimaler Kompilierer 360 sein. Die Schnittstelle 358 für prozessorspezifische Verfahren ermöglicht einen Zugriff auf Ressourcen in dem zugrunde liegenden Betriebssystem. Die Schnittstelle 358 für prozessorspezifische Verfahren kann z. B. eine prozessorspezifische Java-Schnittstelle sein.
  • Die Laufzeit-Datenbereiche 354 enthalten Stapel 364 prozessorspezifischer Verfahren, Java-Stapel 366, PC-Register 368, Verfahrensbereiche 370 und Zusatzdaten 372. Diese unterschiedlichen Datenbereiche repräsentieren die Organisation des Speichers, der durch die JVM 350 benötigt wird, um ein Programm auszuführen.
  • Die Java-Stapel 366 werden verwendet, um den Zustand von Java-Verfahren-Aufrufen zu speichern. Wenn ein neues ausführbares Programmsegment (thread) begonnen wird, erzeugt die JVM einen neuen Java-Stapel für das ausführbare Programmsegment. Die JVM führt lediglich zwei Operationen direkt an Java-Stapeln aus: sie verschiebt Rahmen und holt diese hervor. Ein Java-Stapel des ausführbaren Programmsegments speichert den Zustand der Aufrufe des Java-Verfahrens für das ausführbare Programmsegment. Der Zustand eines Aufrufs eines Java-Verfahrens enthält seine lokalen Variablen, die Parameter, mit denen es aufgerufen wurde, gegebenenfalls seinen Rückkehrwert und Zwischenberechnungen. Java-Stapel sind aus Stapel-Rahmen aufgebaut. Ein Stapel-Rahmen enthält den Zustand eines einzelnen Aufrufs eines Java-Verfahrens. Wenn ein ausführbares Programmsegment ein Verfahren aufruft, verschiebt die JVM einen neuen Rahmen auf den Java-Stapel des ausführbaren Programmsegments. Wenn das Verfahren endet, holt die JVM den Rahmen für dieses Verfahren vor und verwirft es.
  • Die JVM hat keine Register zum Speichern von Zwischenwerten; ein Java-Befehl, der einen Zwischenwert benötigt oder erzeugt, verwendet den Stapel zum Speichern des Zwischenwerts. Auf diese Weise ist der Java-Befehlssatz für eine Vielzahl von Plattform-Architekturen einwandfrei definiert.
  • PC-Register 368 werden verwendet, um den nächsten Befehl anzugeben, der ausgeführt werden soll. Jedes spezialisierte ausführbare Programmsegment erhält sein eigenes Programmzählerregister und seinen eigenen Java-Stapel. Wenn das ausführbare Programmsegment ein JVM-Verfahren ausführt, gibt der Wert des Programmzählerregisters den nächsten Befehl an, der auszuführen ist. Wenn das ausführbare Programmsegment ein prozessorspezifisches Verfahren ausführt, sind die Inhalte des Programmzählerregisters undefiniert.
  • Die Stapel 364 prozessorspezifischer Verfahren speichern den Zustand von Aufrufen der prozessorspezifischen Verfahren. Der Zustand von Aufrufen prozessorspezifischer Verfahren wird in einer von der Realisierung abhängigen Art in Stapel prozessorspezifischer Verfahren, in Registern oder anderen von der Realisierung abhängigen Speicherbereichen gespeichert. Bei einigen JVM-Realisierungen werden die Stapel 364 prozessorspezifischer Verfahren und die Java-Stapel 366 kombiniert.
  • Der Verfahrensbereich 370 enthält Klassendaten, während der Datenstapel 372 alle spezialisierten Objekte enthält. Die JVM-Spezifikation definiert streng Datentypen und Operationen. Die meisten JVMs sind so gewählt, dass sie einen Verfahrensbereich und einen Bereich zusätzlicher Daten haben, wovon jeder durch alle ausführbaren Programmsegmente, die in der JVM ablaufen, gemeinsam verwendet wird. Wenn die JVM eine Klassendatei lädt, analysiert sie syntaktisch Informationen über einen Typ aus den Binärdaten, die in der Klassendatei enthalten sind. Sie platziert diese Typinformationen in dem Verfahrensbereich. Jedes Mal, wenn eine Klasseninstanz oder ein Array erzeugt wird, wird der Speicher für das neue Objekt aus dem Datenstapel 372 zugewiesen. Die JVM 350 enthält einen Befehl, der Speicherraum in dem Speicher für den Datenstapel 372 zuweist, enthält jedoch keinen Befehl, der diesen Raum im Speicher leert.
  • Die Speicherverwaltung 374 verwaltet in dem dargestellten Beispiel Speicherraum in dem Speicher, der den zusätzlichen Steuerung 370 zugewiesen ist. Die Speicherverwaltung 374 kann einen Papierkorb enthalten, der automatisch Speicher zurückgewinnt, der von Objekten verwendet wird, auf die keinen Bezug mehr genommen wird. Der Papierkorb kann zusätzlich außerdem Objekte verschieben, um die Fragmentierung der Stapeldaten zu verringern.
  • Die vorliegende Erfindung ist gleichfalls auf eine plattformspezifische Umgebung, d. h. eine herkömmliche Umgebung von Computeranwendungen, die Module oder prozessorspezifische Verfahren lädt, oder eine plattformunabhängige Umgebung wie etwa eine interpretative Umgebung, z. B. eine Java-Umgebung, die Klassen, Verfahren und dergleichen lädt, anwendbar. Für den Zweck der Erläuterung der Merkmale und Vorteile der vorliegenden Erfindung und um die Fähigkeit der vorliegenden Erfindung des Betriebs in jeder Umgebung hervorzuheben, werden Beispiele des Betriebs der vorliegenden Erfindung in Bezug auf eine Java-Umgebung und auch auf eine herkömmliche Computerbetriebsumgebung beschrieben.
  • Die vorliegende Erfindung stellt einen Mechanismus bereit, durch den eine Mischdatei aus den symbolischen Daten erzeugt wird. Die vorliegende Erfindung stellt außerdem einen Mechanismus bereit, durch den Leistungsablaufverfolgungen von Anwendungen wie etwa Java-Anwendungen und eine symbolische Zerlegung ausgeführt werden können, bei der die symbolischen Daten überprüft werden, ob sie die korrekten symbolischen Daten für eine inkrementale oder geforderte Zerlegung von Adressen sind, z. B. bei Leistungsablaufverfolgungsdaten. Die vorliegende Erfindung stellt außerdem einen Mechanismus bereit, durch den eine indexierte Datenbank symbolischer Daten entweder als eine separate Datei oder als ein separater Abschnitt einer Ablaufverfolgungsdatei erzeugt wird. Während die vorliegende Erfindung auf jede inkrementale oder geforderte Zerlegung symbolischer Daten anwendbar ist, wird die vorliegende Erfindung für Erläuterungszwecke in Bezug auf eine Leistungsablaufverfolgung eines Computerprogramms erläutert.
  • In 4 stellt ein Blockschaubild Komponenten dar, die verwendet werden, um Leistungsablaufverfolgungen von Prozessen in einem Datenverarbeitungssystem auszuführen. Ein Ablaufverfolgungsprogramm 400 wird verwendet, um Prozesse 402 zu profilieren. Das Ablaufverfolgungsprogramm 400 kann verwendet werden, um Daten bei der Ausführung eines Hook aufzuzeichnen, der ein bestimmter Teil eines Codes an einer bestimmten Stelle in einer Routine oder in einem Programm ist, mit der andere Routinen verbunden sein können. Ablaufverfolgungs-Hooks werden typischerweise für den Zweck der Fehlersuche, der Leistungsanalyse oder der Verbesserung der Funktionalität eingefügt. Diese Ablaufverfolgungs-Hooks werden verwendet, um Ablaufverfolgungsdaten an ein Ablaufverfolgungsprogramm 400 zu senden, das die Ablaufverfolgungsdaten im Puffer 404 speichert. Die Ablaufverfolgungsdaten im Puffer 404 können anschließend in einer Datei zur Nachverarbeitung gespeichert oder in Echtzeit verarbeitet werden. Die Ablaufverfolgungsdaten, die sich entweder im Puffer 404 oder in der Ablaufverfolgungsdatei befinden, werden dann durch den Nachprozessor 406 verarbeitet, um eine indexierte Datenbank symbolischer Daten für geladene Module zu erzeugen, wie später genauer beschrieben wird.
  • In einer Nicht-Java-Umgebung verwendet die vorliegende Erfindung Ablaufverfolgungs-Hooks, die bei der Kennzeichnung von Modulen helfen, die in einer Anwendung, die einer Ablaufverfolgung unterzogen wird, verwendet werden. Bei Java-Betriebssystemen verwendet die vorliegende Erfindung Ablaufverfolgungs-Hooks, die beim Kennzeichnen geladener Klassen und Verfahren helfen.
  • Da Klassen und Module außerdem geladen und entladen werden können, können diese Änderungen ebenfalls unter Verwendung von Ablaufverfolgungsdaten gekennzeichnet werden. Dies ist besonders relevant bei "Netzwerk-Client-" Datenverarbeitungssystemen, wie etwa jene, die unter JavaOS betrieben werden, da Klassen und zeitoptimierte Verfahren infolge des beschränkten Speichers und der Rolle als ein Netzwerk-Client häufiger geladen und entladen werden können. Es ist anzumerken, dass Informationen zum Laden und Entladen von Klassen oder Modulen außerdem in Umgebungen mit eingebetteten Anwendungen relevant sind, bei denen die Tendenz zur Speichereinschränkung besteht.
  • In 5 wird eine Darstellung verschiedener Phasen bei der Ausführung einer Leistungsablaufverfolgung der Arbeitsbelastung, die in einem System abläuft, gezeigt. Infolge von Speichereinschränkungen kann die erzeugte Ablaufverfolgungsausgabe so lang und so genau sein, wie es der Analytiker für den Zweck der Profilierung eines bestimmten Programms fordert.
  • Eine Initialisierungsphase 500 wird verwendet, um den Zustand der Client-Maschine zu dem Zeitpunkt, an dem die Ablaufverfolgung ausgelöst wird, zu erfassen. Die Initialisierung der Ablaufverfolgungsdaten enthält Ablaufverfolgungsdatensätze, die alle vorhandenen ausführbaren Programmsegmente, alle geladenen Klassen (Module) und alle Verfahren (Abschnitte) für die geladenen Klassen (Module) kennzeichnen. Datensätze von Ablaufverfolgungsdaten, die von Hooks erfasst werden, werden geschrieben, um Schalter für ausführbare Programmsegmente, Unterbrechungen und das Laden und Entladen von Klassen (Modulen) und "zeitoptimierten" Verfahren (Abschnitten) anzugeben.
  • Jede Klasse (Modul), die geladen ist, weist Ablaufverfolgungsdatensätze auf, die den Namen der Klasse (Modul) und seine Verfahren (Abschnitte) angeben. In dem dargestellten Beispiel werden 4-Byte-Kennungen als Bezeichnung für ausführbare Programmsegmente, Klassen und Verfahren verwendet. Diesen Kennungen sind Namen zugeordnet, die in den Ablaufverfolgungsdatensätzen ausgegeben wurden. Ein Ablaufverfolgungsdatensatz wird geschrieben, um anzuzeigen, wenn alle Anlaufinformationen geschrieben wurden.
  • Anschließend werden während der Profilierungsphase 502 Ablaufverfolgungsdatensätze in einen Ablaufverfolgungspuffer oder eine Ablaufverfolgungsdatei geschrieben. In der vorliegenden Erfindung kann ein Ablaufverfolgungspuffer eine Kombination aus Typen von Datensätzen aufweisen, wie etwa jene, die von einem Ablaufverfolgungs-Hook stammen, der in Reaktion auf eines bestimmt Ereignistyp ausgeführt wurde, z. B. ein Verfahrensbeginn oder ein Verfahrensende, und jene, die von einer Stapel-Verschiebungsfunktion (stack-walking function) stammen können, die in Reaktion auf eine Zeitgeberunterbrechung ausgeführt werden, z. B. ein Stapel-Abwicklungsdatensatz, der auch als ein Aufruf-Stapel-Datensatz bezeichnet wird.
  • Die folgenden Operationen können z. B. während der Profilierungsphase auftreten, wenn der Benutzer des Profilierungsdienstprogramms Profilierungsinformationen anhand von Abtastungen angefordert hat. Jedes Mal, wenn ein bestimmter Typ der Zeitgeberunterbrechung auftritt, wird ein Ablaufverfolgungsdatensatz geschrieben, der den Systemprogrammzähler angibt. Dieser Systemprogrammzähler kann verwendet werden, um die Routine zu kennzeichnen, die unterbrochen wurde. In dem dargestellten Beispiel wird eine Zeitgeberunterbrechung verwendet, um die Gewinnung von Ablaufverfolgungsdaten auszulösen. Es können natürlich andere Typen von Unterbrechungen als Zeitgeberunterbrechungen verwendet werden. Unterbrechungen anhand eines programmierten Leistungsüberwachungsereignisses oder andere Typen von periodischen Ereignissen können z. B. verwendet werden.
  • In der Nachbearbeitungsphase 504 werden die Daten, die im Ablaufverfolgungspuffer gesammelt wurden, verarbeitet oder zu einer Ablaufverfolgungsdatei zur Nachverarbeitung gesendet. In einer Konfiguration kann die Datei zu einem Server gesendet werden, der das Profil für die Prozesse an der Client-Maschine festlegt. Die Nachverarbeitung kann natürlich in Abhängigkeit von den verfügbaren Ressourcen auch an der Client-Maschine ausgeführt werden.
  • Bei der vorliegenden Erfindung enthält die Nachverarbeitung gemäß einer ersten beispielhaften Ausführungsform die Verwendung einer Mischsymboldatei, um symbolische Daten mit Leistungsablaufverfolgungsdaten zu korrelieren, d. h., um eine symbolische Zerlegung auszuführen. Dies kann entweder mit den Leistungsablaufverfolgungsdaten, die im Ablaufverfolgungspuffer gespeichert sind, oder mit den Leistungsablaufverfolgungsdaten in der Ablaufverfolgungsdatei erfolgen. Die Nachverarbeitung kann als eine eingeschlossene Operation ausgeführt werden, so dass die Nachverarbeitung ausgeführt wird, unmittelbar nachdem die Leistungsablaufverfolgung ausgeführt wurde, während der Leistungsablaufverfolgung in Echtzeit oder zu einem Zeitpunkt, der von dem Zeitpunkt entfernt ist, an dem die Leistungsablaufverfolgung ausgeführt wird.
  • Als Teil des Prozesses der symbolischen Zerlegung werden die symbolischen Daten für die Module/Prozesse überprüft, ob sie die korrekten symbolischen Daten für die Versionen der Module/Prozesse in den Leistungsablaufverfolgungsdaten sind. Diese Überprüfung beruht auf verschiedenen Kriterien, zu denen Prüfsumme, Zeitstempel, vollständig qualifizierter Weg, Segmentgrößen und dergleichen zählen.
  • Die symbolische Zerlegung stellt symbolischen Daten für geladene Module/Prozesse der Anwendung, bei der eine Ablaufverfolgung ausgeführt wird, bereit. Als Ergebnis der symbolischen Zerlegung wird eine indexierte Datenbank der symbolischen Daten für die geladenen Module/Prozesse erzeugt. Die indexierte Datenbank kann auf den Leistungsablaufverfolgungsdaten in dem Ablaufverfolgungspuffer oder den Leistungsablaufverfolgungsdaten in der Ablaufverfolgungsdatei beruhen, wie später genauer beschrieben wird.
  • 6 ist eine beispielhafte Darstellung, die die zeitliche Beziehung der verschiedenen Prozesse veranschaulicht, die während der Leistungsablaufverfolgung einer Anwendung und der anschließenden Erzeugung einer indexierten Datenbank für geladene Module/Prozesse verwendet werden. In 6 wird angenommen, dass die Nachverarbeitung der Leistungsablaufverfolgungsdaten zu einer bestimmten Zeit, nachdem die Leistungsablaufverfolgung abgeschlossen wurde, ausgeführt wird. Wie jedoch oben angemerkt wurde, kann die Nachverarbeitung auch während der Leistungsablaufverfolgung ausgeführt werden, so dass dann, wenn die Leistungsablaufverfolgungsdaten in den Ablaufverfolgungspuffer geschrieben wurden, die Nachverarbeitung an den geschriebenen Leistungsablaufverfolgungsdaten ausgeführt wird. Auf diese Weise wird die Zeitdauer, die erforderlich ist, um die Leistungsablaufverfolgung und die Nachverarbeitung abzuschließen, verringert.
  • Wie in 6 gezeigt ist, wird die Leistungsablaufverfolgung zum Zeitpunkt t0 ausgelöst, wenn die Anwendungsausführung begonnen wird. Die Leistungsablaufverfolgung endet zum Zeitpunkt t1, wenn die Anwendungsausführung beendet wird.
  • Nach der Leistungsablaufverfolgung wird zum Zeitpunkt t2 eine Mischsymboldatei der symbolischen Daten für die Anwendung, an der die Ablaufverfolgung ausgeführt wird, erzeugt. Während die 6 die Erzeugung der Mischsymboldatei zeigt, die ausgeführt wird, nachdem die Anwendungsablaufverfolgung abgeschlossen ist, ist die Erfindung nicht auf diese beispielhafte Darstellung beschränkt. Stattdessen kann die Mischsymboldatei erzeugt werden, bevor die Leistungsablaufverfolgung ausgelöst wird oder als Teil der Ablaufverfolgungsbeendigung. Eine alternative beispielhafte Darstellung kann eine symbolische Zerlegung in Echtzeit (während der Ablaufverfolgung) für eine gleichzeitige Anzeige der Ablaufverfolgungsinformationen ausführen.
  • Zu einem Zeitpunkt tn nach der Leistungsablaufverfolgung und der Erzeugung der Mischsymboldatei werden die während der Leistungsablaufverfolgung geladenen oder verwendeten Module/Prozesse ermittelt und eine indexierte Datenbank der symbolischen Daten für die geladenen oder verwendeten Module/Prozesse wird erzeugt. Diese indexierte Datenbank kann als eine Nachverarbeitung der Leistungsablaufverfolgungsdaten in dem Ablaufverfolgungspuffer erzeugt werden, unmittelbar nachdem die Leistungsablaufverfolgung beendet wurde. Die indexierte Datenbank kann alternativ als eine Nachverarbeitung der Leistungsablaufverfolgungsdaten, die in einer Ablaufverfolgungsdatei gespeichert sind, zu einem bestimmten Zeitpunkt, der von der eigentlichen Leistungsablaufverfolgung entfernt ist, erzeugt werden.
  • In 7 stellt ein Ablaufplan eine beispielhafte Operation eines Leistungsablaufverfolgungs-Hilfsprogramms zum Erzeugen von Ablaufverfolgungsdatensätzen aus Modulen/Prozessen dar, die in einem Datenverarbeitungssystem ausgeführt werden. Ablaufverfolgungsdatensätze können durch die Ausführung von kleinen Teilen des Codes, die als "Hooks" bezeichnet werden, erzeugt werden. Hooks können auf verschiedene Arten in den Code, der durch Prozesse ausgeführt wird, statisch (Quellencode) und dynamisch (durch Modifikation einer geladenen Ausführbaren) eingefügt werden. Die in 7 dargestellte Operation wird verwendet, nachdem Ablaufverfolgungs-Hooks bereits in den Prozess oder die Prozesse, die von Interesse sind, eingesetzt wurden. Die Operation beginnt durch Zuweisen eines Puffers (Schritt 700), z. B. des Puffers 404 in 4. Anschließend werden in dem dargestellten Beispiel Ablaufverfolgungs-Hooks eingeschaltet (Schritt 702). Ablaufverfolgungsdaten werden aus den Prozessen, die von Interesse sind, erhalten (Schritt 706). Dieser Typ der Ablaufverfolgung kann z. B. während Phasen 500 und/oder 502 ausgeführt werden. Diese Ablaufverfolgungsdaten werden als Ablaufverfolgungsdatensätze im Puffer gespeichert (Schritt 708).
  • Es wird festgestellt, ob die Ablaufverfolgung abgeschlossen ist (Schritt 710). Die Ablaufverfolgung endet, wenn der Ablaufverfolgungspuffer gefüllt wurde oder der Benutzer die Ablaufverfolgung über einen Befehl anhält und fordert, dass die Pufferinhalte an eine Datei gesendet werden. Wenn die Ablaufverfolgung nicht beendet wurde, kehrt die Operation zum Schritt 706 zurück, wie oben beschrieben wurde. Wenn dagegen die Ablaufverfolgung beendet ist, werden die Pufferinhalte an eine Datei zur Nachverarbeitung gesendet (Schritt 712). Dann wird ein Bericht in der Nachverarbeitung erzeugt (Schritt 714), woraufhin die Operation endet.
  • Obwohl in dem dargestellten Beispiel die Nachverarbeitung verwendet wird, um die Ablaufverfolgungsdatensätze zu analysieren, können die Operationen der vorliegenden Erfindung verwendet werden, um Ablaufverfolgungsdaten in Abhängigkeit von der Realisierung in Echtzeit zu verarbeiten. Wenn die Ablaufverfolgungsdaten in Echtzeit verarbeitet werden, beginnt die Verarbeitung der Ablaufverfolgungsdaten im Ablaufverfolgungspuffer unmittelbar nach dem oben genannten Schritt 710. Durch die Verarbeitung der Ablaufverfolgungsdaten in Echtzeit kann der dynamische Zustand des Systems gekennzeichnet werden. Durch die Verarbeitung der Ablaufverfolgungsdaten in Echtzeit können Profilermittlungsberichte gleichzeitig mit der Programmausführung angezeigt werden.
  • Dieser Lösungsansatz ist besonders nützlich für zeitoptimierte Verfahren. Ein zeitoptimiertes Verfahren wird unmittelbar bevor das Programm abläuft von Bytecodes zum Maschinencode umgesetzt. Bei Java werden zeitoptimierte Verfahren vom Bytecode zu prozessorspezifischem Code umgesetzt. Dadurch kann dem dynamischen Wesen von zeitoptimierten Verfahren durch die dynamische Verarbeitung von Ablaufverfolgungsdaten Rechnung getragen werden. In 8 stellt ein Ablaufplan eine beispielhafte Operation dar, die während eines Ablaufverfolgungs-Hook für ein Unterbrechungs-Bedienprogramm verwendet werden kann. Die Operation beginnt durch Erhalten eines Programmzählers (Schritt 800). Der Programmzähler steht typischerweise in einem der gesicherten Bereiche des Programmstapels zur Verfügung. Anschließend wird festgestellt, ob der Code, der unterbrochen wird, interpretierter Code ist (Schritt 802). Diese Feststellung kann getroffen werden, indem ermittelt wird, ob der Programmzähler in einem Adressenbereich für den Interpreter liegt, der zum Übersetzen von Bytecodes verwendet wird.
  • Wenn der unterbrochene Code interpretierter Code ist, wird eine Verfahrensblockadresse für den Code, der unterbrochen ist, erhalten. Ein Ablaufverfolgungsdatensatz wird dann geschrieben (Schritt 806). Der Ablaufverfolgungsdatensatz wird geschrieben, indem die Ablaufverfolgungsdaten an ein Ablaufverfolgungsprogramm gesendet werden, z. B. an ein Ablaufverfolgungsprogramm 400, das in dem dargestellten Beispiel Ablaufverfolgungsdatensätze für eine Nachverarbeitung erzeugt. Dieser Ablaufverfolgungsdatensatz wird als ein Unterbrechungsdatensatz oder ein Unterbrechungs-Hook bezeichnet.
  • Dieser Typ der Ablaufverfolgung kann während der Phase 502 ausgeführt werden. Alternativ kann ein ähnlicher Prozess, d. h. die Feststellung, ob Code, der unterbrochen wurde, interpretierter Code ist, während der Nachverarbeitung einer Ablaufverfolgungsdatei auftreten. In diesem Fall wird das letzte interpretierte Verfahren, das ausgeführt wird, stets als Teil der Ablaufverfolgungsdatei geschrieben.
  • Wie oben beschrieben wurde, wird vor, während oder nach der Ausführung der Ablaufverfolgung eine Mischsymboldatei der symbolischen Daten für die Anwendung, bei der die Ablaufverfolgung ausgeführt wird, erzeugt. 9 ist eine grafische Darstellung der Erzeugung der Mischsymboldatei gemäß der vorliegenden Erfindung für eine herkömmliche Computerausführungsumgebung.
  • Wie in 9 gezeigt ist, enthält die Mischsymboldatei 910 symbolische Daten für Module, die aus Abbildungsdateien 920, Fehlersuchdateien 930, ungekürzten Versionen von Modulen 930 und anderen Dateien 940 symbolischer Daten erhalten werden. Diese Quellen symbolischer Daten können z. B. im lokalen Speicher 209, auf der Festplatte 232, in einer oder mehreren der Einheiten 276 bis 282 oder in einem anderen Typ der Datenspeichereinheit gespeichert sein. Die Mischsymboldatei 910 kann gleichfalls in einer dieser Speichereinheiten oder dergleichen gespeichert sein.
  • Das Datenverarbeitungssystem der vorliegenden Erfindung ist mit einem vollständig qualifizierten Weg der verschiedenen Quellen symbolischer Daten versehen und kombiniert symbolische Daten, die verschiedene ausführbare Dateien beschreiben, zu einer einzelnen Mischsymboldatei. Eine beispielhafte Ausführungsform des Formats dieser Datei ist in 10A beschrieben.
  • Die sich ergebende Mischsymboldatei hat einen Eintrag (der in der Mischsymboldatei durch einen Kopfbereichdaten-Eintrag (HeaderData entry) abstrakt dargestellt ist) für jedes Modul. Es können mehrere Einträge für Module mit dem gleichen Namen vorhanden sein, wenn z. B. im System mehrere Versionen eines Moduls oder im System unterschiedliche Module mit identischen Namen in verschiedenen Wegen vorhanden sind.
  • 10 ist eine beispielhafte Darstellung, die die Organisation einer Mischsymboldatei gemäß der vorliegenden Erfindung veranschaulicht. Wie in 10A gezeigt ist, ist die Mischsymboldatei hierarchisch organisiert. An der Spitze der Hierarchie stehen Informationen 1001, die die bestimmte Plattform kennzeichnen, auf der sich die Anwendung befindet. Zu diesen Informationen gehören ein Kopfbereich, ein von der Groß- oder Kleinschreibung abhängiger Merker, ein Schrägstrichzeichen und dergleichen.
  • Auf der nächsten Hierarchieebene werden die Mischelemente 1002 gekennzeichnet. Die Mischelemente enthalten eine Anzeige von n Modulen, die durch ihren Modulnamen gekennzeichnet sind, das ist der Basisname ohne Erweiterungen des bestimmten Moduls in der Anwendung.
  • Jedes Mischelement kann 1 bis n unterschiedliche Module darstellen, die den gleichen Basisnamen haben können. Deswegen werden z. B. während der Erzeugung der Mischsymboldatei dann, wenn eine ausführbare Datei foo.exe vorkommt und außerdem eine entsprechende Fehlersuchdatei foo.dbg vorkommt, die symbolischen Daten von diesen beiden Dateien zu einem einzelnen Abbild vermischt (beschrieben durch ein einzelnes Datenelement 1002). Wenn jedoch eine ausführbare Datei foo.exe und eine Fehlersuchdatei mit dem gleichen Basisnamen foo.dbg vorkommen, jedoch festgestellt wird, dass diese nicht dem gleichen Modul entsprechen (wenn sie z. B. eine unterschiedliche Prüfsumme oder einen unterschiedlichen Zeitstempel enthalten, die möglicherweise angeben, dass sie unterschiedlichen Versionen des Moduls entsprechen), werden zwei unterschiedliche Abbilder der Module (dargestellt durch unterschiedliche Datenelemente 1002) mit verschiedenen symbolischen Daten erzeugt.
  • Diese Abbilder der Module werden durch Modul-Kopfbereiche 1003 gekennzeichnet, die den Modulweg, die Erweiterung, die Prüfsumme und den Zeitstempel enthalten. Jedes Abbild des Moduls kann 1 bis n Abschnitte enthalten, wovon jedes eine Sammlung von Routinen, eine Sammlung schreibbarer Datenelemente oder nur lesbarer Datenelemente und dergleichen dargestellt.
  • Diese Abschnitte werden durch einen Abschnitts-Kopfbereich 1004 gekennzeichnet, der den Abschnittsnamen, den Versatz (offset) und die Länge enthält. Jeder Abschnitt kann 1 bis n symbolische Daten 1005 enthalten. Die symbolischen Daten 1005 sind durch den symbolischen Namen, den Versatz von der Spitze des Moduls und/oder eine Länge gekennzeichnet.
  • 10B ist eine beispielhafte Darstellung einer Mischsymboldatei gemäß der vorliegenden Erfindung. In 10B wird eine Nicht-Java-Umgebung angenommen, und sie ist auf bestimmte Module einer Anwendung gerichtet. Wie oben angemerkt wurde, kann die vorliegende Erfindung jedoch gleichfalls bei einer Java-Umgebung angewendet werden.
  • Wie in 10B gezeigt ist, enthält die Mischsymboldatei 1000 einen Mischsymbol-Kopfbereich 1010, eine Mischelementkennung 1020 und einen Modulnamen 1030. Der Mischsymbol-Kopfbereich 1010, die Mischelementkennung 1020 und der Modulname 1030 speichern Informationen darüber, wie die Mischsymboldatei 1000 erzeugt wurde. Diese Elemente speichern außerdem Informationen über das System, in dem die Datei erzeugt wurde (wie z. B. die Anzahl von Prozessoren oder das Betriebssystem, das verwendet wurde). Die Mischelementkennung 1020 bildet einen Index der oberen Ebene in der Mischsymboldatei 1000 durch den Basisnamen.
  • Die Mischsymboldatei enthält des Weiteren Informationen, die jedes Modul betreffen, das den Modulnamen besitzt. Somit sind in dem in 10B gezeigten Beispiel in der Mischsymboldatei zwei Module vorhanden, die den Modulnamen "foo" besitzen. Einträge 1040 und 1050 für jedes der Module sind in der Mischsymboldatei vorgesehen.
  • Jeder Eintrag 1040 und 1050 liefert Informationen 1060, die die Kennzeichnung eines bestimmten Moduls und der symbolischen Daten 1070, die dem Modul zugehörig sind, betreffen. Die symbolischen Daten sind in ladbare Abschnitte unterteilt, die Abschnitt-Kopfbereiche aufweisen. Jeder ladbare Abschnitt besitzt einen Abschnittsnamen, einen Versatz und eine Länge.
  • Die Informationen 1060, die die Kennzeichnung eines bestimmten Moduls betreffen, enthalten Informationen wie den vollständig qualifizierten Weg des Moduls, die Modulerweiterung, eine Prüfsumme und einen Zeitstempel für das Modul. Die symbolischen Daten stellen den Symbolnamen, den Versatz und die Länge für jedes Symbol bereit. Durch die Verwendung des Versatzes und der Länge, die dem Abschnitt und den symbolischen Daten zugehörig sind, kann die genaue Identität der symbolischen Daten bestimmt und mit Adressen in den Leistungsablaufverfolgungsdaten korreliert werden.
  • Zusätzlich zu den obigen Ausführungen kann die Mischsymboldatei ein Maß der "Vertraulichkeit" oder einen Grad der Qualität der Symbole für jedes Modul enthalten. Das Maß der Vertraulichkeit kann z. B. eine Anzeige der Typen von symbolischen Daten sein, die während des Mischprozesses erhalten wurden. Das Maß der Vertraulichkeit kann z. B. eine Anzeige liefern, ob alle exportierbaren Symbole, internen Symbole und statischen Symbole für das bestimmte Modul erhalten wurden. Dieses Maß der Vertraulichkeit kann einem Benutzer mitgeteilt werden für seine Verwendung bei der Bestimmung der Qualität der symbolischen Zerlegung gemäß der vorliegenden Erfindung.
  • Obwohl die in 10B gezeigten Module den gleichen Modulnamen besitzen, handelt es sich um unterschiedliche Module, was aus den Modulinformationen hervorgeht, die in der Mischsymboldatei gespeichert sind. Die Einträge 1040 und 1050 repräsentieren unterschiedliche Module dahingehend, dass der Weg, die Prüfsumme, der Zeitstempel die Länge und die symbolischen Daten für die beiden Module unterschiedlich sind. Die eigentlichen Module können jedoch zwei unterschiedliche Versionen des gleichen Moduls sein. Es ist z. B. möglich, dass eine spätere Version des Moduls "foo.exe" im Verzeichnis "C:\tem\" erzeugt und im Verzeichnis "C:\WINNT\" gespeichert wurde.
  • Wenn die Prüfsumme und der Zeitstempel nicht verfügbar sind oder der Name des vollständig qualifizierten Wegs nicht verwendet wird, sind bekannte Systeme zur Leistungsablaufverfolgung nicht in der Lage zu erkennen, welches der Module das korrekte Modul zum Kennzeichnen der symbolischen Daten, die den Leistungsablaufverfolgungsdatenzugehörig sind, ist. Die bekannten Systeme stellen eine Übereinstimmung anhand des Basisnamens her und sind von Benutzer abhängig, um sicherzustellen, dass die Symbole, die sie bereitstellen, für die korrekten Versionen der Module sind.
  • Windows 2000 von Microsoft Corporation erfordert z. B., dass der Benutzer den Namen des vollständig qualifizierten Wegs zur Quellendatei und zu den symbolischen Daten mit Ausnahme einiger feststehender Konventionen, wie z. B. das Systemverzeichnis im Windows-Betriebssystem, spezifiziert. Dieses Verzeichnis ist in der Umgebungsvariable SystemRoot gekennzeichnet. Dadurch kann z. B. durch den Weg "%SystemRoot%/Systems/" auf einen Standardspeicherort zugegriffen werden. Wenn mehr als ein Modul mit dem gleichen Modulnamen vorhanden sind, entweder als unterschiedliche Module oder als unterschiedliche Versionen des gleichen Moduls, kann somit ein Fehler dadurch auftreten, dass das falsche Modul verwendet wird, um die symbolische Zerlegung auszuführen.
  • Das alleinige Vertrauen auf den vollständig qualifizierten Weg bringt keine Lösung für dieses Problem, da:
    • 1. der vollständig qualifizierte Weg möglicherweise nicht bei allen Systemen zur Verfügung steht;
    • 2. es gelegentlich vorteilhaft ist, Symbole aus einem anderen Verzeichnis zu erzeugen als das eine Verzeichnis, aus dem das System die Module lädt; und
    • 3. der vollständig qualifizierte Weg ist kein fehlerfreies Kriterium für die Übereinstimmung. Wenn die Ablaufverfolgung zu einem Zeitpunkt nachverarbeitet wird, der vom Zeitpunkt der Sammlung der eigentlichen Ablaufverfolgungsinformationen entfernt ist, ist es möglich, dass ein Modul in der Zwischenzeit auf eine neuere Version aktualisiert wurde. In diesem Fall würde der vollständig qualifizierte Weg übereinstimmen, es wäre jedoch nicht erwünscht, an dieser Stelle die Symbole aus dem Modul zu verwenden.
  • Die vorliegende Erfindung stellt einen Mechanismus bereit, der sogar in dem Fall funktioniert, wenn es nicht möglich ist, Ablaufverfolgungsinformationen zu erhalten, die den vollständig qualifizierten Weg enthalten. Außerdem ermöglicht die vorliegende Erfindung, Symbole aus einem anderen Verzeichnis zu erzeugen als das eine Verzeichnis, aus dem das System die Module lädt. Die vorliegende Erfindung ermöglicht z. B. die Nachverarbeitung von Ablaufverfolgungsinformationen und die Erzeugung von Mischsymboldateien in einem System, das nicht das der Prüfung unterzogene System ist. Die vorliegende Erfindung stellt ferner einen Mechanismus bereit, durch den die korrekten symbolischen Daten an die Leistungsablaufverfolgungsdaten angepasst werden. Der Mechanismus verwendet eine Anzahl von Prüfungen, um festzustellen, ob das in der Mischsymboldatei gekennzeichnete Modul das gleiche Modul wie in den Leistungsablaufverfolgungsdaten ist.
  • 11 ist eine beispielhafte Darstellung von Leistungsablaufverfolgungsdaten. Die Leistungsablaufverfolgungsdaten 1100 von 11 können in dem Ablaufverfolgungspuffer gespeichert oder nach der Leistungsablaufverfolgung in eine Ablaufverfolgungsdatei geschrieben werden. Die Ablaufverfolgungsdatei kann z. B. in einer der Speichereinheiten 209, 232, 276 bis 282 oder dergleichen gespeichert sein. Die Leistungsablaufverfolgungsdaten enthalten die folgenden Felder:
    • Feld 1: Hauptcode des Ablaufverfolgungs-Hook;
    • Feld 2: Untercode des Ablaufverfolgungs-Hook;
    • Feld 3: Zeitstempel (obere 32 Bits; untere 32 Bits);
    • Feld 4: nicht verwendet
    • Feld 5: Prozesskennung (pid);
    • Feld 6: Segmentladeadresse
    • Feld 7: Segmentlänge
    • Feld 8: Segmentmerker (Dieses sind Merker, die Zulassungsebenen auf den Seiten angeben, in die die Segmente geladen werden und dergleichen);
    • Feld 9: Modul-Prüfsumme;
    • Feld 10: Modul-Zeitstempel
    • Feld 11: Segmentname; und
    • Feld 12: Modulname.
  • Die Leistungsablaufverfolgungsdaten 1100 enthalten Leistungsablaufverfolgungsdaten für die Ablaufverfolgungs-Hooks für den Modultabelleneintrag (MTE) sowie Ablaufverfolgungs-Hooks des Zeitprofilierers (Tprof).
  • Die Felder für MTE-Ablaufverfolgungs-Hooks in der Ablaufverfolgungsdatei wurden oben beschrieben. Die MTE-Ablaufverfolgungsdaten werden in den Einträgen bereitgestellt, die einen Hauptcode des Ablaufverfolgungs-Hook von 19 und einen Untercode von 38 aufweisen. Die Hauptcodes und Untercodes des Ablaufverfolgungs-Hook von 19 und 38 sind die Hauptcodes und Untercodes, die in der beispielhaften Darstellung verwendet werden, um einen MTE-Hook anzugeben.
  • Andere Codes können verwendet werden, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
  • Für einen Ablaufverfolgungs-Hook (Hauptcode 10 und Untercode 03) sind die Felder etwas anders dahingehend, dass Feld 5 einem Programmzähler, Feld 6 einer pid, Feld 7 der Kennung eines ausführbaren Programmsegments und Feld 8 einer Code-Vorzugsebene entspricht. Die Code-Vorzugsebene gibt die Vorrechte an, die der Ausführungscode besitzt. Die Code-Vorzugsebene kann z. B. angeben, ob der Ausführungscode im Benutzerraum oder im Kernraum ist.
  • Der Hook tprof enthält die Ablaufverfolgungsdaten, die verwendet werden, um das der Prüfung unterzogene System zu profilieren. Zum Zeitpunkt der Nachverarbeitung werden die Verknüpfungen aus pid und Adressen im Hook tprof in Symbole zerlegt. Der Nachprozessor verknüpft die MTE-Informationen und die Mischsymboldatei zu einer indexierten Datenbank. Wenn der Nachprozessor auf einen Hook tprof trifft (oder einen anderen Typ von Ablaufverfolgungsdaten, die Adressdaten enthalten, die in ein Symbol übersetzt werden müssen), sucht er in der Datenbank nach der pid-Adressverknüpfung, um ein entsprechendes Symbol zu erhalten.
  • Die MTE-Informationen enthalten einen Eintrag, der das Laden oder Entladen jedes Abschnitts in einem Modul repräsentiert. Es gibt somit einen getrennten Eintrag für das Laden des Abschnitts .txt, das Laden des Abschnitts PAGE und das Entladen des Abschnitts .txt (wenn jede von diesen Operationen aufgetreten ist) von C:\WINNT\foo.exe. In dem dargestellten Beispiel ist das Laden dieser Abschnitte in den Zeilen gezeigt, die mit "19 38" beginnen. Beispiele von Einträgen zum Entladen sind in den Zeilen gezeigt, die mit "19 39" und "19 44" beginnen. Die Entlade-Einträge, die mit "19 39" beginnen, entsprechen einem Standard-Entlade-Hook. Die Entlade-Einträge, die mit "19 44" beginnen, entsprechen einem Entlade-Hook für ein zeitoptimiertes Verfahren.
  • Die MTE-Hook-Ablaufverfolgungsdaten in den Leistungsablaufverfolgungsdaten können als eine MTE-Datei gespeichert werden. 12 zeigt eine beispielhafte Darstellung einer MTE-Datei 1200. Wie in 12 gezeigt ist, enthält die MTE-Datei 1200 nur die MTE-Einträge in den Leistungsablaufverfolgungsdaten und kennzeichnet dadurch lediglich das Laden und Entladen von Modulen.
  • In einer bevorzugten Ausführungsform der vorliegenden Erfindung ist die MTE-Datei 1200 mit der Mischsymboldatei korreliert, um die symbolischen Daten für die geladenen Module zu kennzeichnen. Die Korrelation von Leistungsablaufverfolgungsdaten mit der Mischsymboldatei kann jedoch anhand der MTE-Einträge in den Leistungsablaufverfolgungsdaten in dem Ablaufverfolgungspuffer oder in der Ablaufverfolgungsdatei wie etwa die in 11 gezeigten Leistungsablaufverfolgungsdaten ausgeführt werden.
  • Um zu überprüfen, dass die Informationen der Mischsymboldatei für das Modul dem gleichen Modul, das in der MTE-Datei gekennzeichnet ist, entsprechen, werden mehrere vergleiche ausgeführt. Zunächst erfolgt ein Vergleich der Prüfsumme und des Zeitstempels für das Modul. Wenn die Prüfsumme und der Zeitstempel, die in der Mischsymboldatei angegeben sind, der Prüfsumme und dem Zeitstempel in der MTE-Datei entsprechen, wird festgelegt, dass die Modulkennungen entsprechen, und die symbolischen Daten in der Mischsymboldatei werden mit den Informationen der MTE-Datei verwendet, um Informationen des geladenen Moduls zu erzeugen.
  • Einige Dateien enthalten keine Prüfsummen- und Zeitstempel-Informationen. Elf-Objekt-Dateien, die in Linux verwendet werden, enthalten z. B. keine Prüfsummen- und Zeitstempel-Informationen und bilden auch keine Abbildungsdateien. Für diese Dateien hat die Prüfsummen- und Zeitstempelprüfung deshalb normalerweise ein negatives Ergebnis. Beispielsweise bei den Abbildungsdateien können jedoch auch andere verwandte Dateien wie etwa .dbg-Dateien in Verbindung mit den Abbildungsdateien verwendet werden, um erforderliche Informationen zum Prüfen der Gültigkeit der Abbildungsdateien bereitzustellen. Wenn die Prüfsumme und der Zeitstempel nicht übereinstimmen oder nicht zur Verfügung stehen, wird der vollständig qualifizierte Weg, der in der MTE-Datei gekennzeichnet ist, an den vollständig qualifizierten Weg in der Mischsymboldatei angepasst. Wenn eine Übereinstimmung vorhanden ist, ist das Modul geprüft und die symbolischen Daten in der Mischsymboldatei, die dem geprüften Moduleintrag entsprechen, werden verwendet, um Informationen des geladenen Moduls zu erzeugen.
  • Wenn der vollständig qualifizierte Weg nicht übereinstimmt, erfolgt ein Vergleich von Segmentgrößen zwischen der Mischsymboldatei und der MTE-Datei. Deswegen wird z. B. die Segmentlänge im Feld 7 der MTE-Datei mit der Segmentlänge für das Segment in der Mischsymboldatei des Moduls, das im Feld 11 der MTE-Datei gekennzeichnet ist, verglichen. Wenn die Segmentlänge entspricht, ist dieses Segment "angepasst". Wenn alle Segmente angepasst sind, ist das Modul geprüft und die symbolischen Daten in der Mischsymboldatei werden verwendet, um Informationen des geladenen Moduls zu erzeugen.
  • Diese Serien von Vergleichen können für jedes Modul in der Mischsymboldatei, das den geeigneten Modulnamen aufweist, ausgeführt werden. Deswegen werden z. B. die oben genannten Vergleiche für das erste "foo"-Modul (Modul-Kopfbereich (0)) ausgeführt und wenn keine Übereinstimmung vorhanden ist, werden sie anschließend für das zweite "foo"-Modul (Modul-Kopfbereich (1)) ausgeführt.
  • In einer alternativen Ausführungsform kann jeder Vergleich unabhängig davon ausgeführt werden, ob ein vorhergehender Vergleich ein geprüftes Modul ergeben hat. Deswegen werden z. B. die Prüfsumme, der Zeitstempel, der vollständig qualifizierte Weg und Segmentgrößen für jedes der "foo"-Module verglichen, und das Modul mit der besten Korrelation wird als das richtige Modul gewählt, das für die Erzeugung von Informationen des geladenen Moduls verwendet wird. Wenn z. B. das erste "foo"-Modul anhand der Segmentgrößen geprüft wurde und das zweite "foo"-Modul anhand des vollständig qualifizierten Weg geprüft wurde, wird das zweite "foo"-Modul zum Erzeugen von Informationen des geladenen Moduls gewählt, da bei dem vollständig qualifizierten Weg eine größere Wahrscheinlichkeit besteht, den korrekten Moduleintrag zu kennzeichnen.
  • Nachdem ein Modul geprüft wurde, wird ein Eintrag der indexierten Datenbank anhand der symbolischen Daten des geprüften Moduls erzeugt. Diese Operation wird für jeden MTE-Eintrag in der Leistungsablaufverfolgungsdatei oder der MTE-Datei ausgeführt.
  • Die Einträge der indexierten Datenbank können anhand eines suchbaren Werts indexiert sein. Die indexierte Datenbank ist z. B. anhand der Prozesskennung (pid) und der Segmentladeadresse indexiert, wobei jedoch andere suchbare Indizes verwendet werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
  • Wenn der Nachprozessor während der Nachverarbeitung in der Leistungsablaufverfolgungsdatei oder der MTE-Datei in Abhängigkeit von der bestimmten Realisierung auf einen MTE-Eintrag trifft, wird das Segment an ein entsprechendes Segment in der Mischsymboldatei angepasst, wie oben beschrieben wurde. Wenn der MTE-Eintrag verarbeitet wird, wird ein Eintrag der indexierten Datenbank erzeugt, wobei die pid und die Segmentladeadresse aus der Leistungsablaufverfolgungsdatei und der Segmentname aus der Mischsymboldatei erhalten werden.
  • 13A ist ein einer vereinfachten indexierten Datenbank 1300 entnommener beispielhafter Abschnitt gemäß der vorliegenden Erfindung. Wie in 13A gezeigt ist, enthalten Einträge in der indexierten Datenbank 1300 einen Index 1310 (pid:Adresse) und entsprechende symbolische Daten 1320, d. h. die Teilroutinennamen. Dadurch kann dann, wenn ein bestimmter Wert pid:Adresse in der Leistungsablaufverfolgungsdatei angetroffen wird, der Wert pid:Adresse in eine bestimmte symbolische Stelle einer bestimmten Stelle in einer ausführbaren Datei umgesetzt werden. Das eigentliche Symbol entspricht einer Teilroutine (oder einem Java-Verfahren).
  • Ein Segment enthält gewöhnlich mehrere Teilroutinen. Dadurch würde ein tprof-Datensatz, wenn er mit pid 2 und der Adresse 80298000 angetroffen wird, in der Version von foo.exe in dem Verzeichnis C:\\temp\ über den Beginn der Teilroutine 2 hinaus in 18000 Bytes zerlegt. Dies kann dargestellt werden als: C:\\temp\foo.exe(subroutine2+0x18000).
  • Wie oben beschrieben wurde, entsteht die indexierte Datenbank 1300 durch einen Prozess der Anpassung von Verknüpfungen pid:Adresse, die aus Daten der MTE-Datei wie etwa die MTE-Datei 1200, erhalten werden, an Abschnittsdaten in der Mischsymboldatei wie etwa die Mischsymboldatei 1000. 13B ist ein Ablaufplan, der einen beispielhaften Betrieb eines Nachprozessors zum Erzeugen der indexierten Datenbank 1300 anhand der MTE-Daten und der Mischsymboldatei umreißt. Wie in 13B gezeigt ist, beginnt der Betrieb damit, dass der Nachprozessor auf einen MTE-Hook in den MTE-Daten trifft (Schritt 1310). Die MTE-Daten kennzeichnen eine pid und eine Adresse. Die pid und die Adresse werden vom Nachprozessor verwendet, um ein Modul und einen Abschnitt in dem Modul in der Mischsymboldatei zu kennzeichnen (Schritt 1320).
  • Der Nachprozessor berechnet dann einen Versatz der Adresse von der Spitze des Moduls, das den Abschnitt enthält (Schritt 1330). Dieser Versatz wird dann vom Nachprozessor verwendet, um die symbolischen Daten für das Symbol zu kennzeichnen (Schritt 1340). Die resultierenden symbolischen Daten werden in der indexierten Datenbank zusammen mit pid:Adresse gespeichert (1350). Die indexierte Datenbank 1300 kann als eine getrennte Datei in einem Speichermedium wie etwa eine Festplatte 232 oder eine Platte 276, im Speicher wie etwa der lokale Speicher 209 oder der Speicher 274 gespeichert werden, oder er kann als ein getrennter Teil der Leistungsablaufverfolgungsdatei gespeichert werden, wenn die Leistungsablaufverfolgungsdatei in ein Speichermedium geschrieben wird. Die indexierte Datenbank 1300 kann z. B. am Ende der Leistungsablaufverfolgungsdatei gespeichert werden, so dass dann, wenn eine Leistungsanalyse durch einen Benutzer ausgeführt wird, die Informationen der Leistungsablaufverfolgungsdatei verwendet werden können, um die bestimmten Module und Segmente der Anwendung, die geladen wurden, zu kennzeichnen.
  • Auf diese Weise kann ein Benutzer der Hilfsprogramme der Leistungsablaufverfolgung der vorliegenden Erfindung eine Analyse der Leistung einer Anwendung ausführen, indem er die bestimmten geladenen Module und Segmente der Anwendung kennzeichnet. Der Benutzer kann außerdem den Umfang der Berechnungszeit bestimmen, die durch bestimmte Module und Segmente benötigt wird, um Abschnitte der Anwendung zu kennzeichnen, die für die bestimmte Plattform, auf der Anwendung abläuft, optimiert werden können.
  • 14 ist ein Ablaufplan, der einen beispielhaften Betrieb des Datenverarbeitungssystems gemäß der vorliegenden Erfindung umreißt, wenn eine indexierte Datenbank symbolischer Daten anhand einer Leistungsablaufverfolgung eines Computerprogramms, das eine Anwendung darstellt, erzeugt wird. Obwohl der Ablaufplan eine bestimmte Reihenfolge der Schritte zeigt, ist damit keine Festlegung einer Reihenfolge vorgesehen. Stattdessen können viele der Schritte zu verschiedenen Zeitpunkten während des Betriebs des Datenverarbeitungssystems ausgeführt werden, z. B. beim Erfassen symbolischer Daten und Speichern der symbolischen Daten in einer Mischsymboldatei, was vor, während oder nach der Ausführung einer Ablaufverfolgung ausgeführt werden kann.
  • Wie in 14 gezeigt ist, wird eine Ablaufverfolgung des Computerprogramms ausgeführt (Schritt 1410), und eine Ablaufverfolgungsdatei wird erzeugt (Schritt 1420). Wie oben beschrieben wurde, kann sich diese Ablaufverfolgungsdatei im Ablaufverfolgungspuffer befinden, oder sie kann in eine Speichereinheit geschrieben werden.
  • Informationen geladener Module werden erzeugt und gespeichert (Schritt 1430). Dies kann z. B. erfolgen, indem die MTE-Datei erzeugt wird, die lediglich das Laden und Entladen von Modulsegmenten kennzeichnet, wie oben beschrieben wurde. Die symbolischen Daten für das Computerprogramm werden erfasst (Schritt 1440) und in einer Mischsymboldatei gespeichert (Schritt 1450).
  • Die symbolischen Daten können anhand eines Benutzers erfasst werden, der den Ort von Dateien, die die symbolischen Daten enthalten, kennzeichnet. Das Erfassen der symbolischen Daten kann alternativ auf Dateien beruhen, die den gleichen Dateinamen haben wie das Computerprogramm, das einer Ablaufverfolgung unterzogen wird, oder die in einem im Voraus definierten Verzeichnis gespeichert sind.
  • Die Mischsymboldatei wird dann mit Daten der geladenen Module verknüpft, um symbolische Daten geladener Module zu erzeugen (Schritt 1460). Diese Verknüpfung kann die Vergleiche und die Prüfung von Modulen enthalten, wie oben beschrieben wurde. Die symbolischen Daten geladener Module werden dann indexiert und als Datei einer indexierten Datenbank gespeichert (Schritt 1470). Die Datei der indexierten Datenbank kann im Speicher gespeichert werden, als eine getrennte Datei gespeichert werden, die in eine Speichereinheit geschrieben wird, oder als ein getrennter Abschnitt der Leistungsablaufverfolgungsdatei gespeichert werden, die in eine Speichereinheit geschrieben wird, wie oben beschrieben wurde.
  • Der Ablaufplan von 14 beschreibt den Betrieb der vorliegenden Erfindung bei Verwendung einer Mischsymboldatei zum Liefern symbolischer Daten, die vorliegende Erfindung ist jedoch nicht auf die Verwendung einer Mischsymboldatei beschränkt. Stattdessen kann jede Quelle symbolischer Daten, die geprüft werden kann, verwendet werden, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
  • 15 ist ein Ablaufplan, der einen beispielhaften Betrieb des Datenverarbeitungssystems der vorliegenden Erfindung umreißt, wenn eine indexierte Datenbank symbolischer Daten anhand von Leistungsablaufverfolgungsdaten, die als ein getrennter Abschnitt der Leistungsablaufverfolgungsdatei gespeichert sind, dynamisch erzeugt wird. Obwohl der Ablaufplan wie bei 14 eine bestimmte Reihenfolge von Schritten zeigt, ist die Festlegung einer Reihenfolge nicht vorgesehen, und viele der Schritte können in anderen Reihenfolgen als die gezeigte Reihenfolge ausgeführt werden.
  • Die in 15 gezeigten Schritte werden für neue Leistungsablaufverfolgungsdaten, die in den Ablaufverfolgungspuffer geschrieben werden, wiederholt. Auf diese Weise wird eine indexierte Datenbank symbolischer Daten dynamisch erzeugt, wenn die Anwendung einer Ablaufverfolgung unterzogen wird.
  • Wie in 15 gezeigt ist, beginnt der Betrieb mit einer Leistungsablaufverfolgung des Computerprogramms, das ausgeführt wird (Schritt 1510), und es wird eine Ablaufverfolgungsdatei erzeugt (Schritt 1520). Die Ablaufverfolgungsdatei wird nach Einträgen geladener Module durchsucht (Schritt 1530) und symbolische Daten für die geladenen Module werden erhalten (Schritt 1540). Die symbolischen Daten werden vorzugsweise aus einer Mischsymboldatei erhalten, wie oben beschrieben wurde, es kann jedoch jede Quelle symbolischer Daten, die geprüft werden können, verwendet werden, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
  • Nachdem die symbolischen Daten für die geladenen Module erhalten wurden, werden die symbolischen Daten als ein getrennter Abschnitt der Ablaufverfolgungsdatei gespeichert, die lediglich die Ablaufverfolgungsdatei für die geladenen Module enthält (Schritt 1550). Diese symbolischen Daten werden dann indexiert, um eine indexierte Datenbank symbolischer Daten für die geladenen Module als ein getrennter Abschnitt der Ablaufverfolgungsdatei zu erzeugen (Schritt 1560).
  • Dadurch wird unter Verwendung des oben beschriebenen Betriebs eine indexierte Datenbank symbolischer Daten für geladene Module erhalten. Diese indexierte Datenbank wird in einer bevorzugten Ausführungsform erhalten, indem symbolische Daten aus mehreren Quellen in einer Mischsymboldatei gesammelt werden und anschließend diese Mischsymboldatei mit Leistungsablaufverfolgungsdaten verglichen werden, die entweder im Ablaufverfolgungspuffer oder in einer Ablaufverfolgungsdatei in einer Speichereinheit gespeichert sind. Übereinstimmende symbolische Daten werden dann in Übereinstimmung mit den Leistungsablaufverfolgungsdaten in eine indexierte Datenbank geschrieben.
  • 16 ist ein Ablaufplan, der einen Betrieb der vorliegenden Erfindung umreißt, wenn die Mischsymboldatei mit den Leistungsablaufverfolgungsdaten verglichen wird, um symbolischen Daten des Moduls zu prüfen. Obwohl in 16 eine bestimmte Reihenfolge der Schritte gezeigt ist, können viele der Schritte in anderen Reihenfolgen ausgeführt werden. Die Prüfung der Segmentgröße kann z. B. vor der Prüfung des vollständig qualifizierten Wegs ausgeführt werden und dergleichen.
  • Wie in 16 gezeigt ist, beginnt der Betrieb mit einer Prüfung der Prüfsumme und des Zeitstempels für die symbolischen Daten, die in der Mischsymboldatei und in den Leistungsablaufverfolgungsdaten gespeichert sind (Schritt 1610). Anschließend wird festgestellt, ob eine Übereinstimmung der symbolischen Daten der Mischsymboldatei und der Leistungsablaufverfolgungsdaten vorhanden ist (Schritt 1620). Wenn eine Übereinstimmung vorhanden ist, wird der Betrieb im Schritt 1670 fortgesetzt, andernfalls wird festgestellt, ob die symbolischen Daten von einem ausführbaren Modul stammen (Schritt 1630). Diese Feststellung kann z. B. getroffen werden, indem ermittelt wird, ob die Erweiterung des Moduls, das in der Mischsymboldatei bereitgestellt wird, ".exe" lautet.
  • Wenn die symbolischen Daten nicht von einem ausführbaren Modul stammen, wird der Betrieb im Schritt 1660 fortgesetzt, andernfalls wird eine Prüfung des vollständig qualifizierten Wegs des Moduls ausgeführt (Schritt 1640). Es wird festgestellt, ob die Prüfung des vollständig qualifizierten Wegs angibt, dass das die symbolischen Daten des Moduls in der Mischsymboldatei mit den Leistungsablaufverfolgungsdaten übereinstimmen (Schritt 1650). Wenn eine Übereinstimmung vorhanden ist, wird der Betrieb im Schritt 1670 fortgesetzt, andernfalls wird die Segmentgröße geprüft (Schritt 1660).
  • Es wird festgestellt, ob das Modul durch eine der oben genannten Prüfungen geprüft wurde (1670). Wenn das nicht der Fall ist, wird eine Fehlermeldung zurückgeführt (1680). Wenn das Modul geprüft wurde, werden die symbolischen Daten für das Modul in der Mischsymboldatei an die Leistungsablaufverfolgungsdaten angepasst (Schritt 1690), und der Betrieb endet.
  • Wie oben beschrieben wurde, kann die Prüfung der symbolischen Daten für ein Modul mit den Leistungsablaufverfolgungsdaten auf dem ersten übereinstimmenden Moduleintrag in der Mischsymboldatei beruhen oder eine Bestimmung der "besten Übereinstimmung" der symbolischen Daten für das Modul beinhalten. Diese Bestimmung der "besten Übereinstimmung" kann die Bestimmung einer Übereinstimmung für jeden Moduleintrag in der Mischsymboldatei für einen bestimmten Modulnamen und das Kennzeichnen, welcher Moduleintrag eine beste Übereinstimmung darstellt, beinhalten. Die beste Übereinstimmung kann anhand der bestimmten Attribute ermittelt werden, die verwendet werden, um die Übereinstimmung herzustellen.
  • Die Attribute können deswegen mit Prioritäten versehen werden, um ein Mittel zum Bestimmen der besten Übereinstimmung bereitzustellen. Beispielsweise können die Prüfsumme und der Zeitstempel eine höchste Priorität haben, der vollständig qualifizierte Weg eine zweihöchste Priorität haben und die Segmentgröße eine drittgrößte Priorität haben.
  • 17 ist ein Ablaufplan eines beispielhaften Betriebs der vorliegenden Erfindung, wenn eine beste Übereinstimmung der symbolischen Daten in der Mischsymboldatei mit den Leistungsablaufverfolgungsdaten ermittelt wird. Wie in 17 gezeigt ist, beginnt der Betrieb mit der Prüfung des ersten Moduleintrags in der Mischsymboldatei mit den Informationen des geladenen Moduls in den Leistungsablaufverfolgungsdaten (Schritt 1710). Es wird festgestellt, ob eine Übereinstimmung der symbolischen Daten mit den Leistungsablaufverfolgungsdaten vorhanden ist (Schritt 1720). Wenn das nicht der Fall ist, wird der nächste Moduleintrag in der Mischsymboldatei geprüft (Schritt 1740). Wenn eine Übereinstimmung vorhanden ist, wird festgestellt, ob die Übereinstimmung auf der Prüfsumme und dem Zeitstempel beruht (Schritt 1730). Wenn die Übereinstimmung auf der Prüfsumme und dem Zeitstempel beruht, ist sie die beste Übereinstimmung, und der Betrieb endet. Wenn die Übereinstimmung nicht auf der Prüfsumme und dem Zeitstempel beruht, wird der nächste Moduleintrag in der Mischsymboldatei geprüft (Schritt 1740), und es wird festgestellt, ob der nächste Moduleintrag eine bessere Übereinstimmung als der erste Moduleintrag darstellt (Schritt 1750).
  • Dies kann, wie oben beschrieben wurde, auf einem Prioritätsschema beruhen, das für die bestimmten Attribute eingestellt ist, die zum Prüfen der Moduleinträge verwendet werden. Es kann z. B. ein Merker gesetzt sein, der einen Zeiger zu dem Modul in der Mischsymboldatei, das eine Übereinstimmung ergibt, und eine Zahl angibt, die den Grad der Zuverlässigkeit in der Übereinstimmung darstellt. Die Übereinstimmungskriterien können mit Prüfsumme und Zeitstempel an erster Stelle, vollständig qualifiziertem Weg an zweiter Stelle und Abschnittslängen an dritter Stelle klassifiziert sein. Dadurch würde eine 1, eine 2 oder eine 3 aufgezeichnet, um die Güte der Übereinstimmung anzugeben. Diese Übereinstimmung wird dann mit einer folgenden Übereinstimmung verglichen, und die Übereinstimmung mit dem höheren Maß an Zuverlässigkeit wird gespeichert. Diese Zuverlässigkeitsanzeige kann in eine Nachricht übersetzt werden, die einem Benutzer mitgeteilt wird.
  • Wenn in 17 der nächste Moduleintrag eine bessere Übereinstimmung darstellt, wird der nächste Moduleintrag in der Mischsymboldatei als das übereinstimmende Modul gewählt (Schritt 1760), und der Betrieb kehrt zurück zum Schritt 1730. Wenn das nächste Modul keine bessere Übereinstimmung darstellt, wird festgestellt, ob weitere Moduleinträge zum Prüfen vorhanden sind (Schritt 1770). Wenn das der Fall ist, geht der Betrieb zurück zum Schritt 1740, andernfalls endet der Betrieb.
  • Wie oben beschrieben wurde, stellt die vorliegende Erfindung einen Mechanismus bereit, durch den eine indexierte Datenbank symbolischer Daten für geladene Module erzeugt wird. Die indexierte Datenbank kann als ein Analysewerkzeug verwendet werden, so dass dem Benutzer eine symbolische Darstellung der geladenen Module dargeboten wird anstelle von Prozesskennungen und Adressen, die schwieriger zu verstehen sind.
  • 18 zeigt einen Ablaufplan, der einen beispielhaften Betrieb der vorliegenden Erfindung umreißt, wenn die indexierte Datenbank verwendet wird, um eine symbolische Darstellung von Leistungsablaufverfolgungsdaten für eine Analyse durch einen Benutzer bereitzustellen. Wie in 18 gezeigt ist, beginnt der Betrieb mit dem Lesen der Ablaufverfolgungsdatei (Schritt 1810). Die Prozesskennung (pid), und die Adressendaten werden aus der Ablaufverfolgungsdatei erhalten (Schritt 1820).
  • Die indexierte Datenbank wird dann nach einem Eintrag durchsucht, der der pid und der Adresse entspricht (Schritt 1930). Es wird festgestellt, ob eine Übereinstimmung gefunden wurde (Schritt 1840). Wenn das der Fall ist, werden die entsprechenden symbolischen Daten in Übereinstimmung mit der Ablaufverfolgungsdatei verwendet (Schritt 1850). Die bestimmte Weise, in der die symbolischen Daten verwendet werden, hängt von bestimmten Analyseanwendungen und/oder dem Zweck dieser Anwendungen ab. Anschließend oder dann, wenn keine Übereinstimmung vorhanden ist, wird festgestellt, ob das Ende der Ablaufverfolgungsdatei erreicht ist (Schritt 1860). Wenn das nicht der Fall ist, kehrt der Betrieb zum Schritt 1810 zurück, andernfalls endet der Betrieb.
  • Somit wird mit der vorliegenden Erfindung ein Mechanismus bereitgestellt, durch den eine Mischsymboldatei symbolischer Daten erzeugt wird. Die vorliegende Erfindung stellt außerdem einen Mechanismus bereit, durch den Leistungsablaufverfolgungen von Anwendungen wie etwa Java-Anwendungen und eine symbolische Zerlegung ausgeführt werden können, bei denen die symbolischen Daten geprüft werden, ob sie die korrekten symbolischen Daten für die Leistungsablaufverfolgungsdaten sind. Die vorliegende Erfindung stellt außerdem einen Mechanismus bereit, durch den eine indexierte Datenbank entweder als eine getrennte Datei oder als ein getrennter Abschnitt einer Ablaufverfolgungsdatei erzeugt wird.
  • Die oben beschriebene Erfindung kann dynamische Darstellungen der Leistungsablaufverfolgung durch Verwendung von Informationen der MTE-Datei bereitstellen, um das Laden und Entladen von Modulen zu kennzeichnen. In einigen Fällen ist es vorzuziehen, statische Darstellungen der Leistungsablaufverfolgung zu verschiedenen Zeitpunkten während der Ablaufverfolgung zu haben.
  • Gegenwärtig bekannte Nachverarbeitungswerkzeuge verwenden eine einzelne statische Darstellung für die symbolische Adresse zu Nameninformationen für die Ablaufverfolgung eines Computerprogramms. Diese statische Darstellung wird typischerweise in zwei Teilen erzeugt. Der erste Teil ist die Erzeugung der MTE-Daten, die die geladenen Module am Beginn der Ablaufverfolgung darstellen. Der zweite Teil verwendet diese MTE-Daten und das Symbol für diese geladenen Module und erzeugt die statische Darstellung, die durch ihre Erweiterung .bbf bekannt ist. Diese MTE-Daten treten typischerweise als Teil der anfänglichen Initialisierung der Ablaufverfolgung (strace) auf. Die MTE-Daten können alternativ am Ende der Ablaufverfolgung gesammelt werden. Das Erhalten der MTE-Daten am Beginn der Ablaufverfolgung behandelt nicht den Fall, bei dem Module während der Ablaufverfolgung geladen werden. Das Erhalten der MTE-Daten am Ende der Ablaufverfolgung behandelt nicht den Fall, bei dem Module während der Ablaufverfolgung oder nach der Ablaufverfolgung und bevor die MTE-Daten gesammelt werden, entladen werden.
  • Die .bbf-Datei ist ein statisches Bild davon, welche Module zu einem bestimmten Zeitpunkt der Ablaufverfolgung geladen sind, und der entsprechenden Symbole der geladenen Module. Die .bbf-Datei unterscheidet sich von der Mischsymboldatei dahingehend, dass die Mischsymboldatei symbolische Daten für alle Module eines Computersystems enthält und die .bbf-Datei lediglich symbolische Daten für geladene Module enthält. Die .bbf-Datei stellt eine Sammlung von Programmen und anderem ausführbaren Code dar, der in alle Prozesse des Computersystems geladen wird.
  • 19 ist ein Beispiel eines Abschnitts einer typischen .bbf-Datei für ein Computerprogramm. Wie gezeigt ist, hat die .bbf-Datei ein pid-orientiertes Format, bei dem die ausführbaren Verfahren in der pid nach Adressen geordnet sind, die Segmente sind nach Adressen geordnet, und die Symbole in den ausführbaren Verfahren sind im Segment nach Adressen geordnet.
  • Wie oben erwähnt wurde, wird die .bbf-Datei in bekannten Nachverarbeitungswerkzeugen entweder am Beginn (strace) oder am Ende der Ablaufverfolgung des Computerprogramms erzeugt. Deswegen sind die einzigen Informationen, die der Analytiker aus der .bbf-Datei bestimmen kann, die Verfahren, die zu dem Zeitpunkt, als das Computerprogramm ausgelöst wurde, oder zum Zeitpunkt der Beendigung der Ablaufverfolgung geladen waren. Deswegen gibt es bei den bekannten Nachverarbeitungswerkzeugen keine Möglichkeit der Bereitstellung symbolischer Daten für Module, die nach der anfänglichen Initialisierung und vor der Beendigung der Ablaufverfolgung dynamisch geladen und entladen wurden.
  • Die vorliegende Erfindung verwendet die Mischsymboldatei und Ablaufverfolgungsinformationen, um mehrere .bbf-Dateien zu erzeugen, um festzustellen, welche Module während der Ablaufverfolgung geladen oder verwendet wurden. Eine symbolische Zerlegung kann unter Verwendung aller .bbf-Dateien ausgeführt werden, so dass dann, wenn ein Modul nicht in einer .bbf-Datei gefunden wird, es in einer der anderen .bbf-Dateien gefunden werden kann.
  • In dieser zweiten beispielhaften Darstellung der vorliegenden Erfindung wird die Mischsymboldatei durch den Nachprozessor gemeinsam mit den Informationen der MTE-Datei verwendet, um statische Darstellungen, z. B. .bbf-Dateien der Ablaufverfolgung des Computerprogramms zu erzeugen. Diese statischen Darstellungen werden in der beispielhaften Darstellung am Beginn (strace) und am Ende der Ablaufverfolgung erzeugt. Auf diese Weise enthält die statische Darstellung am Beginn die Module, die geladen sind, wenn das Computerprogramm initialisiert wird. Die statische Darstellung am Ende kennzeichnet die Module, die während der Ablaufverfolgung geladen waren. Aus diesen Informationen können Module gekennzeichnet werden, die am Beginn der Ablaufverfolgung geladen waren und entladen wurden. Es ist außerdem möglich, Module zu kennzeichnen, die während der Ablaufverfolgung dynamisch geladen wurden.
  • Der Unterschied zwischen einem geladenen Modul und einem verwendeten Modul besteht darin, dass ein Modul geladen werden kann und niemals verwendet wird, d. h., die Ablaufverfolgungsdatensätze nehmen niemals Bezug auf das Modul. Die tritt dann auf, wenn ein Modul nicht eine ausreichend lange Zeit ausgeführt wird, um durch das Signal des Zeitgebers einer Profiliereinrichtung unterbrochen zu werden. Ein Modul kann gleichfalls zu einem Zeitpunkt geladen, verwendet und anschließend entladen werden. Durch den Aufbau einer statischen Darstellung der Ablaufverfolgung am Beginn und am Ende der Ablaufverfolgung kann festgestellt werden, welche Module bei der Initialisierung geladen waren, welche dieser Module verwendet wurden, welche dieser Module nicht verwendet wurden und welche dieser Module während der Ablaufverfolgung geladen und verwendet oder nicht verwendet wurden. Wenn z. B. ein Modul einen Eintrag in der statischen Darstellung hat, die am Beginn der Ablaufverfolgung erzeugt wird, jedoch keinen Eintrag in der statischen Darstellung am Ende der Ablaufverfolgung hat, kann festgestellt werden, dass das Modul geladen, verwendet und anschließend entladen wurde. Wenn die statische Darstellung gleichfalls am Ende der Ablaufverfolgung einen Eintrag für ein Modul hat, das keinen Eintrag in der statischen Darstellung hat, die am Beginn der Ablaufverfolgung erzeugt wurde, muss das Modul während der Ablaufverfolgung geladen und nicht verwendet worden sein.
  • Die MTE-Datei enthält Informationen in Bezug auf geladene Module. Unter Verwendung der Mischsymboldatei in der Weise, die oben in Bezug auf das Ausführen einer symbolischen Zerlegung zum Erzeugen einer indexierten Datenbank dargestellt wurde, kann eine symbolische Zerlegung von Adressendaten für die geladenen Module ausgeführt werden. Die Modulinformationen in der Ablaufverfolgungsdatei/im Ablaufverfolgungspuffer werden beispielsweise verwendet, um Module in der Mischsymboldatei zu kennzeichnen, um dadurch eine indexierte Datenbank symbolischer Daten zu erzeugen. Diese indexierte Datenbank symbolischer Daten kann dann gemeinsam mit der MTE-Datei verwendet werden, um eine .bbf-Datei unter Verwendung von symbolischen Versätzen vom Beginn der Module und dergleichen für einen bestimmten Fall in der Ablaufverfolgung des Computerprogramms zu erzeugen. Die Erzeugung der .bbf-Datei kann z. B. sowohl am Beginn als auch am Ende der Ablaufverfolgung ausgeführt werden.
  • Dadurch kann unter Verwendung der MTE-Datei und der Mischsymboldatei eine statische Darstellung der Ablaufverfolgung des Computerprogramms für verschiedene Zeitpunkte während der Ablaufverfolgung, z. B. am Beginn und am Ende der Ablaufverfolgung, erzeugt werden. Diese Informationen können dann gespeichert und verwendet werden, um symbolische Darstellungen der Ablaufverfolgungsdaten bereitzustellen. Da die statische Darstellung lediglich geladene Module repräsentiert und die statischen Darstellungen für eine endliche Anzahl von Zeitpunkten in der Ablaufverfolgung erzeugt werden, kann der Umfang von Daten, die für eine symbolische Zerlegung gespeichert werden, auf ein Mindestmaß verringert werden.
  • Dadurch kann bei der vorliegenden Erfindung der Nachprozessor während der Nachverarbeitung die strace- .bbf-Datei verwenden, um eine symbolische Zerlegung der Adressendaten auszuführen. Wenn ein Modul in der strace- .bbf-Datei nicht gefunden werden kann, d. h., das Modul wurde während der Ablaufverfolgung dynamisch geladen, kann die .bbf-Datei, die am Ende der Ablaufverfolgung erzeugt wird, verwendet werden, um die symbolische Zerlegung auszuführen. Dadurch kann durch die Erzeugung mehrerer .bbf-Dateien während der Ausführung einer Ablaufverfolgung eines Computerprogramms eine symbolische Zerlegung von dynamisch geladenen Modulen ausgeführt werden.
  • Aus dem Beispiel der .bbf-Datei, die oben in 19 gezeigt ist, ist es klar, dass dann, wenn mehrere Verfahren vorhanden sind, eine große Anzahl duplizierter Informationen, die in den .bbf-Dateien gespeichert sind. Wenn z. B. ein Modul mehrere Segmente aufweist, werden die Modulinformationen für das Segment für jeden Prozess, der das gleiche Modul besitzt, wiederholt.
  • Durch die vorliegende Erfindung wird in einem weiteren Beispiel eine große Menge dieser doppelten Informationen in Bezug auf Systeme, bei denen der vollständig qualifizierte Weg zu einem Modul während der Ablaufverfolgung bekannt ist, durch Kennzeichnen jedes geladenen Moduls durch seinen vollständig qualifizierten Weg während der Initialisierung der anfänglichen Ablaufverfolgung (strace) beseitigt. 20 ist eine beispielhafte Darstellung eines Abschnitts einer .bbf-Datei gemäß der vorliegenden Erfindung.
  • Wie in 20 gezeigt ist, ist die .bbf-Datei wegorientiert. Das heißt, die Module werden durch den vollständig qualifizierten Weg gekennzeichnet. Die .bbf-Datei ist wegorientiert aufgebaut und besitzt lediglich einen Eintrag für jedes Modul. Dies kann erfolgen, indem die pid für das Modul auf einen Platzhalter, z. B. "????", gesetzt wird. Dieser Platzhaltereintrag gibt an, dass der Moduleintrag in der .bff-Datei unabhängig von der pid ist. Bei Modulen, die von der pid unabhängig sind, wird die Anfangsadresse auf null gesetzt, und alle Adressen für die Segmente und die symbolischen Daten sind relative Adressen. Das heißt, die Adressen sind relativ zur Anfangsadresse von Null. Wenn der vollständig qualifizierte Weg eines Moduls bekannt ist, wird die .bbf-Datei mit dem "????" für die pid aufgebaut. Wenn der vollständig qualifizierte Weg des Moduls nicht bekannt ist, wird die pid in der .bff-Datei gekennzeichnet.
  • Wenn eine symbolische Zerlegung unter Verwendung der .bbf-Datei gemäß dieser weiteren beispielhaften Darstellung der vorliegenden Erfindung ausgeführt wird, kann das Modul durch seinen vollständig qualifizierten Weg in der .bbf-Datei "nachgeschlagen" werden. Wenn anhand des vollständig qualifizierten Wegs keine Übereinstimmung vorhanden ist, kann das Modul anschließend anhand der pid "nachgeschlagen" werden. Da die pid für Module in der .bbf-Datei der vorliegenden Erfindung auf einen Platzhalter gesetzt ist, wird jeder Moduleintrag in der .bbf-Datei geprüft, um in ähnlicher Weise wie oben in Bezug auf die Prüfung von Modulen unter Verwendung der Mischsymboldatei festzustellen, ob eine Übereinstimmung anhand der Segmentgröße, der symbolischen Adressendaten und dergleichen vorhanden ist.
  • Dadurch wird mit der vorliegenden Erfindung der Umfang von Informationen, die in der .bbf-Datei gespeichert sind, auf ein Mindestmaß verringert, während trotzdem die Fähigkeit aufrechterhalten wird, die .bbf-Datei während der symbolischen Zerlegung nach übereinstimmenden Moduleinträgen zu durchsuchen.
  • Es ist bei einem Betriebssystem üblich, Segmente oder Abschnitte eines Moduls stückweise zu laden. Daher kann eine Ausführung eines bestimmten Segments eines Moduls erfolgen, bevor alle Segmente für das Modul geladen wurden. Des Weiteren können einige Segmente des Moduls während der Ablaufverfolgung niemals geladen werden oder ihre Ablaufverfolgungsdatensätze, die geladen wurden, können nicht verfügbar sein. Die vorliegende Erfindung stellt einen Mechanismus bereit, durch den eine symbolische Zerlegung für die Segmente eines Moduls ausgeführt werden kann, ohne dass erforderlich ist, dass das gesamte Modul geladen wird oder Ablaufverfolgungsdatensätze für das gesamte Modul verfügbar sind.
  • Wie oben erwähnt wurde und in der repräsentativen Ablaufverfolgungsdatei und der MTE-Datei in den 11 und 12 gezeigt ist, kann die vorliegende Erfindung redundante Informationen in die Ablaufverfolgungsdaten schreiben. Diese redundanten Informationen enthalten z. B. die Prüfsumme des Moduls, den Zeitstempel des Moduls und den vollständig qualifizierten Weg des Moduls.
  • Da es nicht möglich ist, die Reihenfolge, in der Segmente geladen werden, im Voraus zu kennen, enthält jeder der Ablaufverfolgungsdatensätze ausreichende Informationen für den Nachprozessor, um ein Abbild des Moduls aufzubauen. Diese Informationen werden verwendet, um das Segment in dem Ablaufverfolgungsdatensatz an den Abschnitt des Moduls in der Mischsymboldatei anzupassen.
  • Um ein Segment, das durch einen Ablaufverfolgungsdatensatz dargestellt wird, an einen bestimmten Abschnitt in einem Modul, das in der Mischsymboldatei dargestellt ist, anzupassen, werden die folgenden Kriterien berücksichtigt. Wenn sowohl der Segmentname in dem Ablaufverfolgungsdatensatz als auch der Abschnittsname in der Mischsymboldatei nicht null sind und übereinstimmen, stimmen das Segment und der Abschnitt überein. Wenn sowohl der Segmentname in dem Ablaufverfolgungsdatensatz als auch der Abschnittsname in der Mischsymboldatei null sind und in dem Modul lediglich ein Segment vorhanden ist, muss dies das Segment sein, das in dem Ablaufverfolgungsdatensatz gekennzeichnet ist. Wenn sowohl der Segmentname in dem Ablaufverfolgungsdatensatz als auch der Abschnittsname in der Mischsymboldatei null sind und die Adressen übereinstimmen, stimmen das Segment und der Abschnitt überein. Wenn beide Namen null sind und die Größen in Bytes übereinstimmen, stimmen das Segment und der Abschnitt überein.
  • Wenn das Segment und der Abschnitt übereinstimmen, können die symbolischen Daten in der oben beschriebenen Weise in die indexierte Datenbank geschrieben werden. Dadurch stellt die vorliegende Erfindung ein Mittel bereit zum Ausführen einer symbolischen Zerlegung von Segmenten in Modulen, selbst wenn das gesamte Modul nicht geladen wurde und Ablaufverfolgungsdatensätze für alle Segmente eines Moduls nicht verfügbar sind.
  • In den beispielhaften Darstellungen, die oben beschrieben wurden, werden die Ablaufverfolgungsdaten in die Ablaufverfolgungsdatei oder die MTE-Datei geschrieben, wenn Segmente von Modulen geladen oder entladen werden. Deswegen gibt es redundante Eintrage für jedes Segment, die beseitigt werden können, wobei trotzdem eine symbolische Zerlegung ausgeführt werden kann. Durch das Entfernen dieser redundanten Eintrage kann die Größe der Ablaufverfolgungsdatei stark verringert werden.
  • In einigen Systemen kann der Kern aktualisiert werden, um ein Statusfeld hinzuzufügen, das geladenen Modulen zugehörig ist. Alternativ kann eine Kernerweiterung verwendet werden, um dieses Statusfeld bereitzustellen.
  • Bei der vorliegenden Erfindung besitzt der aktualisierte Kern dann, wenn ein Modul geladen ist, im Zusammenhang mit dem Modul einen Ablaufverfolgungsmerker "verwendet (oder in Bezug genommen)", der der pid des Moduls zugeordnet ist. Wenn das Modul geladen ist, wird dieser Merker auf null gelöscht. Deswegen gibt der Merker an, dass das Modul geladen wurde, jedoch noch nicht verwendet oder Bezug darauf genommen wurde. Wenn beispielsweise eine Anwendung mit zeitlicher Profilierung läuft und während der Ablaufverfolgung ein Zeitprofil-Ablaufverfolgungs-Hook angetroffen wird, wird der Merker "verwendet" für das unterbrochene Modul in der unterbrochenen pid durch das Ablaufverfolgungsprogramm auf eins gesetzt. Wenn das Modul entladen wird, kann der modifizierte Kern den Merker "verwendet" (der im Folgenden mit UF bezeichnet wird) prüfen, um festzustellen, ob er gesetzt wurde. Wenn UF gesetzt wurde, kann das Ablaufverfolgungsprogramm MTE-Ablaufverfolgungsdatensätze, die dem Modul vor dem Entladen des Moduls zugeordnet sind, ausgeben. Gleichfalls können am Ende der Ablaufverfolgung alle geladenen Module geprüft werden, und bei jedem Modul, bei dem der UF gesetzt ist, können MTE-Ablaufverfolgungsdatensätze geschrieben werden. Während der Nachverarbeitung werden symbolische Daten für alle Module, bei denen Datensätze aus MTE-Daten vorhanden sind, d. h. für alle Module, bei denen Bezugnahmen auf Ablaufverfolgungsdaten vorhanden sind, gesammelt.
  • Während die Ablaufverfolgung nachverarbeitet wird und die Ausführung einer symbolischen Zerlegung versucht wird, werden die Ablaufverfolgungsdatensätze nacheinander verarbeitet, wobei nach dem ersten MTE-Eintrag nach dem Ablaufverfolgungsbezug gesucht wird. Aus diesem MTE-Eintrag und den symbolischen Daten in der Mischsymboldatei kann die Adresse zur Namenzerlegung bestimmt werden. In einem alternativen Beispiel werden bei der ersten Bezugnahme die MTE-Daten für das in Bezug genommene Modul vor dem Schreiben des Ablaufverfolgungsdatensatzes geschrieben. Bei diesem Lösungsansatz muss der Nachprozessor nach der Ablaufverfolgungsreferenz nicht nach den MTE-Daten suchen, da sie bereits durch den Nachprozessor gelesen wurden.
  • In einem weiteren alternativen Beispiel kann eine Hash-Tabelle erzeugt werden, wobei die pid ein Schlüssel zur Hash-Tabelle ist. Die Daten in der Hash-Tabelle können eine Liste von Modulen enthalten, die der pid zugeordnet sind. Die Hash-Tabelle kann Merker enthalten, die mehrere Zustände des Moduls angeben, darunter ob die Ablaufverfolgungsdaten für das Modul bereits geschrieben wurden, ob zuvor auf das Modul Bezug genommen wurden, ob das Modul geladen und entladen wurde und dergleichen. Diese Merker können in der gleichen Weise wie der oben beschriebene UF verwendet werden. Mit anderen Worten, anhand der Einstellungen dieser Merker kann festgestellt werden, ob die die Ablaufverfolgungsdaten in eine Ablaufverfolgungsdatei geschrieben werden sollen. Auf diese Weise kann der gleiche Typ des Schemas, der oben verwendet wurde, durch eine Kernerweiterung, die die Kerndatenstrukturen nicht modifiziert, entwickelt werden.
  • Deswegen ist in diesem weiteren Beispiel der vorliegenden Erfindung die Anzahl von Ablaufverfolgungsdatensätzen verringert, und die Ablaufverfolgungsdatei ist demzufolge auf eine Mindestgröße verkleinert. Durch Verkleinerung der Ablaufverfolgungsdatei auf eine Mindestgröße wird außerdem die Dauer der Nachverarbeitungszeit verringert. Außerdem wird durch das Schreiben der Modul-Ablaufverfolgungsdaten vor dem Schreiben des Ablaufverfolgungsdatensatzes der Umfang der Suche, die durch den Nachprozessor ausgeführt wird, verringert, wodurch die Nachverarbeitung beschleunigt wird.
  • 21 ist ein Ablaufplan, der einen beispielhaften Betrieb der vorliegenden Erfindung gemäß diesem weiteren Beispiel umreißt. Wie in 21 gezeigt ist, beginnt der Betrieb mit der Initialisierung der Ablaufverfolgungsdatei beim Beginn einer Ablaufverfolgung eines Computerprogramms. Während der Initialisierung werden Daten von anfänglich geladenen Modulen, z. B. MTE-Daten für jene Prozesse und Verfahren, die am Beginn der Ablaufverfolgung geladen sind, in die Ablaufverfolgungsdatei geschrieben (Schritt 2110). Eine Hash-Tabelle wird für alle momentan geladenen Prozess-Kennungen und die zugehörigen Module gebildet (Schritt 2120). Dies beinhaltet die Erzeugung eines Eintrags in die Hash-Tabelle für jede pid und außerhalb der pid einer Liste von Modulen, die der pid zugehörig sind. Modulinformationen wie etwa Adresse und optional die Länge der Module können in der Hash-Tabelle enthalten sein.
  • Jedes Modul in der Hash-Tabelle enthält ferner einen Ablaufverfolgungsdaten-Merker, der angibt, ob die Ablaufverfolgungsdaten für dieses Modul in die Ablaufverfolgungsdatei oder den Ablaufverfolgungspuffer geschrieben wurden. Da bei der Initialisierung alle Einträge in der Hash-Tabelle Prozessen und Verfahren entsprechen, die im Schritt 2110 in die Ablaufverfolgungsdatei oder den Ablaufverfolgungspuffer geschrieben wurden, sind die Ablaufverfolgungsdaten-Merker für diese Einträge eingeschaltet worden (Schritt 2130).
  • Die Ablaufverfolgung wird dann ausgeführt (Schritt 2140), und es wird festgestellt, ob während der Ablaufverfolgung ein MTE-Ablaufverfolgungs-Hook angetroffen wird (Schritt 2150). Wenn das nicht der Fall ist, wird festgestellt, ob ein Profil-Hook angetroffen wird (Schritt 2160). Wenn kein Profil-Hook angetroffen wird, wird die Ablaufverfolgung durch Rückkehr zum Schritt 2140 fortgesetzt. Wenn ein Profil-Hook angetroffen wird, wird das Modul, in dem der Profil-Hook angetroffen wird, in Bezug auf pid und Moduladresse in der Hash-Tabelle nachgeschlagen (Schritt 2170). Anschließend wird festgestellt, ob der Ablaufverfolgungsdaten-Merker für das Modul ausgeschaltet wurde, d. h., die Ablaufverfolgungsdaten sind nicht in die Ablaufverfolgungsdatei oder den Ablaufverfolgungspuffer geschrieben worden (Schritt 2180). Wenn der Ablaufverfolgungsdaten-Merker ausgeschaltet ist, werden die Ablaufverfolgungsdaten in die Ablaufverfolgungsdatei geschrieben, und der Ablaufverfolgungsdaten-Merker wird eingeschaltet (Schritt 2190). Daraufhin oder dann, wenn der Ablaufverfolgungsdaten-Merker im Schritt 2180 eingeschaltet ist, werden die Profil-Hook-Ablaufverfolgungsdaten in die Ablaufverfolgungsdatei geschrieben (Schritt 2200). Die Ablaufverfolgung kann dann bei Bedarf fortgesetzt werden (Schritt 2300).
  • Wenn im Schritt 2150 ein MTE-Hook angetroffen wird, wird die Hash-Tabelle nach der pid, die dem MTE-Hook zugeordnet ist, durchsucht (Schritt 2210). Es wird festgestellt, ob in der Hash-Tabelle ein Eintrag für die pid vorhanden ist (Schritt 2220). Wenn das nicht der Fall ist, wird der Hash-Tabelle ein Eintrag unter Verwendung der pid angefügt (Schritt 2230).
  • Anschließend oder dann, wenn ein Eintrag auf Grundlage der pid in der Hash-Tabelle gefunden wird, wird die Hash-Tabelle nach der Moduladresse, die dem MTE-Hook zugeordnet ist, durchsucht (Schritt 2240). Es wird dann festgestellt, ob ein Moduleintrag auf Grundlage der Moduladresse gefunden wurde (Schritt 2250). Wenn das nicht der Fall ist, wird der Hash-Tabelle ein Eintrag unter Verwendung der Moduladresse angefügt (Schritt 2260). Das Hinzufügen des Moduleintrags erfolgt in Verbindung mit der pid in dem MTE-Hook.
  • Wenn im Schritt 2250 ein Moduleintrag gefunden wird, wird festgestellt, ob eine teilweise oder vollständige Überlagerung des Moduleintrags erforderlich ist (Schritt 2270). Wenn das der Fall ist, wird der Moduleintrag mit den Modulinformationen, die dem MTE-Hook zugehörig sind, überlagert (Schritt 2260). Bei einer teilweisen Überlagerung kann dies die Einstellung der Länge der vorhandenen Moduleinträge und anschließend das Einfügen der Modul-Informationen, die dem MTE-Hook zugehörig sind, beinhalten, Für eine vollständige Modulüberlagerung kann dies das Löschen eines vorhandenen Moduleintrags und seine Ersetzung mit einem neuen Moduleintrag anhand der Modulinformationen, die dem MTE-Hook zugehörig sind, beinhalten.
  • Eine teilweise oder vollständige Überlagerung kann z. B. dann auftreten, wenn ein Prozess angehalten wird und ein neuer Prozess unter Verwendung der gleichen pid wie im vorhergehenden Prozess erzeugt wird. In einem derartigen Fall kann der Moduleintrag mit einem neuen Moduleintrag überlagert werden. In einem alternativen Beispiel kann die Ablaufverfolgungsdatei einen getrennten Ablaufverfolgungseintrag enthalten, der das Anhalten eines Prozesses und die Erzeugung eines neuen Prozesses unter Verwendung der gleichen pid angibt. Daraufhin werden alle weiteren Bezugnahmen auf die pid unter Verwendung des neuen Moduleintrags aufgelöst.
  • Daraufhin wird der Ablaufverfolgungsdaten-Merker für das Modul ausgeschaltet (Schritt 2290). Es wird festgestellt, ob die Ablaufverfolgung fortgesetzt werden soll (Schritt 2300). Wenn das der Fall ist, kehrt der Betrieb zum Schritt 2140 zurück. Andernfalls endet der Betrieb. Während der Nachverarbeitung werden die MTE-Daten für die Datei(en) eingelesen und in der zeitlichen Reihenfolge verwendet.
  • Wie oben beschrieben wurde, kann die Funktionalität der Hash-Tabelle zum Speicher von Status-Merkern und dergleichen durch Aktualisieren des Kerns, um einen Status-Merker hinzuzufügen, der geladenen Modulen zugewiesen ist, oder durch Vorsehen einer Kernerweiterung ausgeführt werden. Gleichfalls kann eine lokale Prozessspeichereinheit zum Aufrechterhalten dieses Statusmerkers verwendet werden. Alternativ kann ein Prozesssteuerblock des Betriebssystems direkt modifiziert werden, um diesen Statusmerker aufrechtzuerhalten.
  • Während die vorliegende Erfindung im Kontext eines vollständig funktionierenden Datenverarbeitungssystems beschrieben wurde, ist es wichtig anzumerken, dass ein Fachmann erkennen wird, dass die Prozesse der vorliegenden Erfindung in Form eines computerlesbaren Mediums von Befehlen und in einer Vielfalt von Formen verteilt werden können, und dass die vorliegende Erfindung in gleicher Weise gültig ist, unabhängig vom bestimmten Typ des signaltragenden Mediums, das tatsächlich verwendet wird, um die Verteilung auszuführen. Zu Beispielen von computerlesbaren Medien gehören Medien des aufzeichnungsfähigen Typs wie etwa eine Diskette, ein Plattenlaufwerk, ein RAM und CD-ROMs sowie Medien des Übertragungstyps wie etwa digitale und analoge Datenübertragungsverbindungen.
  • Die Beschreibung der vorliegenden Erfindung erfolgte für die Zwecke der Erläuterung und Beschreibung, sie sollte jedoch für die Erfindung in der offenbarten Form nicht erschöpfend oder einschränkend sein. Viele Modifikationen und Variationen werden für den erkennbar sein. Die Ausführungsform wurde ausgewählt und beschrieben, um die Grundgedanken der Erfindung und die praktische Anwendung am besten zu beschreiben und um zu ermöglichen, dass Nichtfachleute die Erfindung in verschiedenen Ausführungsformen mit zahlreichen Modifikationen, die für die bestimmte vorgesehene Verwendungsart geeignet sind, verstehen können.
  • Zusammenfassend stellt die Erfindung eine Vorrichtung und ein Verfahren zum Katalogisieren von symbolischen Daten zur Verwendung bei der Leistungsanalyse von Computerprogrammen bereit. Die Vorrichtung und das Verfahren speichern symbolische Daten für geladene Module während oder kurz nach einer Leistungsablaufverfolgung und verwenden die gespeicherten symbolischen Daten, wenn zu einem späteren Zeitpunkt eine Leistungsanalyse ausgeführt wird. Eine Mischsymboldatei wird für ein Computerprogramm oder eine Anwendung, das bzw. die einer Ablaufverfolgung unterzogen wird, erzeugt. Die Mischsymboldatei enthält Informationen, die nützlich sind bei der Ausführung einer symbolischen Zerlegung von Adressendaten in Ablaufverfolgungsdateien für jedes Beispiel eines Moduls. Während der Nachverarbeitung der Ablaufverfolgungsinformationen, die durch eine Leistungsablaufverfolgung eines Computerprogramms erzeugt werden, werden symbolische Daten, die in der Mischsymboldatei gespeichert sind, mit den Ablaufverfolgungsdaten, die in der Ablaufverfolgungsdatei gespeichert sind, verglichen. Die korrekten symbolischen Daten in der Mischsymboldatei für geladene Module werden anhand einer Anzahl von Bewertungskriterien gekennzeichnet. Die korrekten symbolischen Daten für geladene Module können dann in einer indexierten Datenbank gespeichert werden, die verwendet wird, um Adressendaten in entsprechende symbolische Daten zu zerlegen, wenn die Ablaufverfolgungsinformationen für eine Verwendung durch einen Benutzer an eine Anzeige bereitgestellt werden.

Claims (15)

  1. Verfahren zum Kennzeichnen symbolischer Daten für geladene Module, die einem Computerprogramm zugeordnet sind, das einer Leistungsanalyse unterzogen wird, wobei das Verfahren die folgenden Schritte umfasst: Lesen von Ablaufverfolgungsdaten für ein geladenes Modul; wobei die Ablaufverfolgungsdaten wenigstens ein Attribut zum Kennzeichnen des geladenen Moduls umfassen; Vergleichen des wenigstens einen Attributs mit dem entsprechenden Attribut bzw, den entsprechenden Attributen, das bzw. die das geladene Modul, das in einer Symboldatei enthalten ist, kennzeichnet bzw. kennzeichnen, wobei die Symboldatei symbolische Daten umfasst, die aus einer Vielzahl von Quellen symbolischer Daten mit dem Computerprogramm kombiniert sind und wobei jedes Attribut eine zugehörige Priorität besitzt; und Verwenden der Priorität, um symbolische Daten in der Symboldatei zu bestimmen, die mit den Ablaufverfolgungsdaten am besten übereinstimmen.
  2. Verfahren nach Anspruch 1, bei dem das Attribut eine Prüfsumme und/oder einen Zeitstempel und/oder einen vollständig qualifizierten Weg und/oder eine Segmentgröße umfasst.
  3. Verfahren nach Anspruch 1 oder 2, bei dem die Ablaufverfolgungsdaten aus einem Ablaufverfolgungspuffer gelesen werden.
  4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem die Ablaufverfolgungsdaten aus einer Ablaufverfolgungsdatei, die in eine Speichervorrichtung geschrieben wurde, gelesen werden.
  5. Verfahren nach einem der Ansprüche 1 bis 4, bei dem der Leseschritt und der Anpassungsschritt dynamisch ausgeführt werden, wenn Ablaufverfolgungsdaten in einen Ablaufverfolgungspuffer geschrieben werden.
  6. Verfahren nach einem der Ansprüche 1 bis 4, bei dem der Leseschritt und der Vergleichsschritt zu einem von dem Zeitpunkt, an dem die Ablaufverfolgungsdaten in eine Ablaufverfolgungsdatei geschrieben werden, entfernten Zeitpunkt ausgeführt werden.
  7. Verfahren nach einem vorhergehenden Anspruch, bei dem der Vergleichsschritt den Schritt des Vergleichens einer Prüfsumme und eines Zeitstempels in den Ablaufverfolgungsdaten mit einer Prüfsumme und einem Zeitstempel in den symbolischen Daten in der Symboldatei umfasst.
  8. Verfahren nach Anspruch 7, bei dem der Vergleichsschritt den Schritt des Vergleichens eines vollständig qualifizierten Wegs in den Ablaufverfolgungsdaten mit einem vollständig qualifizierten Weg in den symbolischen Daten umfasst, wenn die Prüfsumme und der Zeitstempel in den Ablaufverfolgungsdaten nicht mit der Prüfsumme und dem Zeitstempel in den Symboldaten übereinstimmen oder die Prüfsumme und der Zeitstempel nicht zur Verfügung stehen.
  9. Verfahren nach Anspruch 8, bei der Anpassungsschritt den Schritt des Vergleichens einer Segmentlänge in den Ablaufverfolgungsdaten mit einer Segmentlänge in den symbolischen Daten umfasst, wenn der vollständig qualifizierte Weg in den Ablaufverfolgungsdaten nicht mit dem vollständig qualifizierten Weg in den symbolischen Daten des Moduls übereinstimmt.
  10. Verfahren nach einem vorhergehenden Anspruch, bei dem das Attribut Prüfsumme, Zeitstempel, einen vollständig qualifizierten Weg und eine Segmentgröße umfasst und die Prüfsumme und der Zeitstempel eine höchste Priorität besitzen und die Segmentgröße eine niedrigste Priorität besitzt.
  11. Verfahren nach einem vorhergehenden Anspruch, bei dem die Ablaufverfolgungsdaten redundante Daten enthalten, die für jedes Segment des Moduls ein Modul kennzeichnen.
  12. Verfahren nach Anspruch 11, bei dem die redundanten Daten eine Prüfsumme des Moduls und/oder einen Zeitstempel des Moduls und/oder einen vollständig qualifizierten Weg des Moduls enthalten.
  13. Verfahren nach einem vorhergehenden Anspruch, das ferner die folgenden Schritte umfasst: Korrelieren der symbolischen Daten mit den Ablaufverfolgungsdaten, um korrelierte Daten zu erzeugen, und Anzeigen der korrelierten Daten.
  14. Vorrichtung zum Kennzeichnen symbolischer Daten für geladene Module, die einem Computerprogramm zugeordnet sind, das einer Leistungsanalyse unterzogen wird, wobei die Vorrichtung Folgendes umfasst: einen Prozessor, der mit einer Speichereinheit für Ablaufverfolgungsdaten und einer Speichereinheit für symbolische Daten verbunden werden kann, wobei der Prozessor folgende Funktionen ausführen kann: Lesen von Ablaufverfolgungsdaten für ein geladenes Modul von der Speichereinheit für Ablaufverfolgungsdaten, wobei die Ablaufverfolgungsdaten wenigstens ein Attribut zum Kennzeichnen des geladenen Moduls umfassen; Vergleichen des wenigstens einen Attributs mit dem entsprechenden Attribut oder den entsprechenden Attributen, das bzw. die das geladene Modul kennzeichnet bzw. kennzeichnen, wobei die Symboldatei symbolische Daten umfasst, die aus einer Vielzahl von Quellen symbolischer Daten kombiniert sind, die dem Computerprogramm zugeordnet sind, und jedes Attribut eine zugehörige Priorität besitzt; und Verwenden der Priorität, um symbolische Daten in der Symboldatei zu bestimmen, die mit den Ablaufverfolgungsdaten am besten übereinstimmen.
  15. Computerprogramm, das Programmcodemittel umfasst, die in der Lage sind, alle Schritte der Ansprüche 1 bis 13 auszuführen, wenn das Programm auf einem Computer abläuft.
DE60130840T 2000-07-10 2001-07-06 Vorrichtung und Verfahren zur Katalogisierung von symbolischen Daten zur Verwendung bei der Leistungsanalyse von Computerprogrammen Expired - Lifetime DE60130840T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US613190 1990-11-14
US09/613,190 US6988263B1 (en) 2000-07-10 2000-07-10 Apparatus and method for cataloging symbolic data for use in performance analysis of computer programs

Publications (2)

Publication Number Publication Date
DE60130840D1 DE60130840D1 (de) 2007-11-22
DE60130840T2 true DE60130840T2 (de) 2008-07-17

Family

ID=24456243

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60130840T Expired - Lifetime DE60130840T2 (de) 2000-07-10 2001-07-06 Vorrichtung und Verfahren zur Katalogisierung von symbolischen Daten zur Verwendung bei der Leistungsanalyse von Computerprogrammen

Country Status (5)

Country Link
US (1) US6988263B1 (de)
EP (1) EP1172729B1 (de)
AT (1) ATE375556T1 (de)
DE (1) DE60130840T2 (de)
ES (1) ES2291278T3 (de)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0002174D0 (en) * 2000-01-31 2000-03-22 Sgs Thomson Microelectronics Design flow checker
AU2001250581A1 (en) * 2000-02-07 2001-08-14 Insignia Solutions Plc Preprocessing of interfaces to allow fast call of native elements
US7058786B1 (en) * 2002-01-17 2006-06-06 Hewlett-Packard Development Company Operating system data communication method and system
JP2007524875A (ja) * 2003-01-10 2007-08-30 ネクサウェブ テクノロジーズ インコーポレイテッド ネットワーク・ベースの処理のためのシステムおよび方法
US20040181562A1 (en) * 2003-03-13 2004-09-16 Piotr Findeisen System and method for determining deallocatable memory in a heap
US7954086B2 (en) * 2003-05-19 2011-05-31 Hewlett-Packard Development Company, L.P. Self-describing kernel modules
CA2433750A1 (en) * 2003-06-27 2004-12-27 Ibm Canada Limited - Ibm Canada Limitee Automatic collection of trace detail and history data
US7730451B2 (en) * 2003-12-26 2010-06-01 Microsoft Corporation Source server
US7360203B2 (en) 2004-02-06 2008-04-15 Infineon Technologies North America Corp. Program tracing in a multithreaded processor
US7657875B2 (en) * 2005-04-12 2010-02-02 International Business Machines Corporation System and method for collecting a plurality of metrics in a single profiling run of computer code
US7640539B2 (en) * 2005-04-12 2009-12-29 International Business Machines Corporation Instruction profiling using multiple metrics
US7739668B2 (en) * 2005-05-16 2010-06-15 Texas Instruments Incorporated Method and system of profiling applications that use virtual memory
US7802149B2 (en) * 2005-05-16 2010-09-21 Texas Intruments Incorporated Navigating trace data
US7548911B2 (en) * 2005-05-28 2009-06-16 Microsoft Corporation Diagnosing problems in distributed systems
JP2007241419A (ja) * 2006-03-06 2007-09-20 Fujitsu Ltd 入力支援装置、入力支援プログラムおよび入力支援方法
US7444499B2 (en) * 2006-03-28 2008-10-28 Sun Microsystems, Inc. Method and system for trace generation using memory index hashing
US7716646B2 (en) * 2006-05-11 2010-05-11 Rekha Kaushik Loading a chain of processors from an XML file
JP4972994B2 (ja) * 2006-05-17 2012-07-11 ソニー株式会社 情報処理装置および情報処理方法、並びにプログラム
WO2008026957A1 (en) * 2006-08-30 2008-03-06 Intel Corporation A split stage call sequence restoration method
EP1918812A1 (de) * 2006-11-01 2008-05-07 Hewlett-Packard Development Company, L.P. Softwareentwicklungssystem
JP5299272B2 (ja) * 2007-04-12 2013-09-25 富士通株式会社 分析プログラムおよび分析装置
US8271956B2 (en) * 2008-02-07 2012-09-18 International Business Machines Corporation System, method and program product for dynamically adjusting trace buffer capacity based on execution history
US20090228875A1 (en) * 2008-03-04 2009-09-10 Devries Alex Method and System for Reducing Disk Allocation by Profiling Symbol Usage
US8117602B2 (en) 2008-04-01 2012-02-14 Kaspersky Lab, Zao Method and system for monitoring execution performance of software program product
US8356285B2 (en) * 2009-03-31 2013-01-15 Oracle America, Inc. Facilitated introspection of virtualized environments
US9058421B2 (en) * 2009-06-16 2015-06-16 Freescale Semiconductor, Inc. Trace correlation for profiling subroutines
US8352907B2 (en) * 2009-08-10 2013-01-08 International Business Machines Corporation Software application recreation
CN102231130B (zh) * 2010-01-11 2015-06-17 国际商业机器公司 计算机系统性能分析方法和装置
US8756580B2 (en) * 2010-03-23 2014-06-17 International Business Machines Corporation Instance-based field affinity optimization
EP2587379B1 (de) 2010-06-28 2023-05-10 Hyundai Motor Company Systemtestvorrichtung
US8397245B2 (en) 2010-07-12 2013-03-12 International Business Machines Corporation Managing loading and unloading of shared kernel extensions in isolated virtual space
US8448169B2 (en) 2010-07-12 2013-05-21 International Business Machines Corporation Managing unique electronic identification for kernel extensions in isolated virtual space
US8527989B2 (en) 2010-07-12 2013-09-03 International Business Machines Corporation Tracking loading and unloading of kernel extensions in isolated virtual space
CA2800271A1 (en) * 2010-09-07 2012-03-15 Ewha University-Industry Collaboration Foundation System test method
US8869113B2 (en) * 2011-01-20 2014-10-21 Fujitsu Limited Software architecture for validating C++ programs using symbolic execution
RU2459236C1 (ru) * 2011-07-19 2012-08-20 Федеральное государственное военное образовательное учреждение высшего профессионального образования "Военная академия связи им. маршала Советского Союза С.М. Буденного" Министерства обороны Российской Федерации Способ и система контроля за выполнением программ с помощью трассировки
US9606783B2 (en) * 2013-10-14 2017-03-28 International Business Machines Corporation Dynamic code selection based on data policies
US9558096B2 (en) * 2014-03-21 2017-01-31 Marvell World Trade Ltd. Method and apparatus for supporting performance analysis
US10514904B2 (en) * 2014-04-24 2019-12-24 Hewlett Packard Enterprise Development Lp Dynamically applying a patch to a computer application
WO2016068845A1 (en) * 2014-09-01 2016-05-06 Hewlett Packard Enterprise Development Lp Dynamically applying a patch to a shared library
WO2018071431A1 (en) 2016-10-11 2018-04-19 Green Hills Software, Inc. Systems and methods for summarization and visualization of trace data
JP6526357B2 (ja) * 2016-11-29 2019-06-05 三菱電機株式会社 制御装置およびプログラム更新方法
US11115494B1 (en) * 2020-02-26 2021-09-07 International Business Machines Corporation Profile clustering for homogenous instance analysis

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0396833A1 (de) 1989-05-12 1990-11-14 International Business Machines Corporation Anordnung zur Ablaufverfolgung in einer Mehrprozessbetriebsumgebung
US5659753A (en) * 1991-02-27 1997-08-19 Digital Equipment Corporation Interface for symbol table construction in a multilanguage optimizing compiler
JP2777496B2 (ja) * 1991-02-28 1998-07-16 インターナショナル・ビジネス・マシーンズ・コーポレイション コンピュータシステムにおいてマルチプロセスをプロファイリングする際の使用方法
US5452449A (en) * 1991-07-03 1995-09-19 Itt Corporation Interactive multi-module source code analyzer that matches and expands call and entry statement parameters
US5450586A (en) * 1991-08-14 1995-09-12 Hewlett-Packard Company System for analyzing and debugging embedded software through dynamic and interactive use of code markers
US5574898A (en) * 1993-01-08 1996-11-12 Atria Software, Inc. Dynamic software version auditor which monitors a process to provide a list of objects that are accessed
JPH06231047A (ja) 1993-02-05 1994-08-19 Fujitsu Ltd アドレス変換方法および装置
US5408665A (en) 1993-04-30 1995-04-18 Borland International, Inc. System and methods for linking compiled code with extended dictionary support
CA2185222A1 (en) * 1994-03-14 1995-09-21 Daniel D. O'dowd Optimizing time and testing of higher level language programs
US5699275A (en) * 1995-04-12 1997-12-16 Highwaymaster Communications, Inc. System and method for remote patching of operating code located in a mobile unit
US5933642A (en) 1995-04-17 1999-08-03 Ricoh Corporation Compiling system and method for reconfigurable computing
EP0830611A4 (de) 1995-06-02 2007-05-09 Cisco Systems Inc Telekontrolle von computerprogrammen
JP3290567B2 (ja) 1995-08-24 2002-06-10 富士通株式会社 プロファイル計装方法
US5748878A (en) * 1995-09-11 1998-05-05 Applied Microsystems, Inc. Method and apparatus for analyzing software executed in embedded systems
US5784553A (en) 1996-01-16 1998-07-21 Parasoft Corporation Method and system for generating a computer program test suite using dynamic symbolic execution of JAVA programs
US5809145A (en) 1996-06-28 1998-09-15 Paradata Systems Inc. System for distributing digital information
US6314558B1 (en) * 1996-08-27 2001-11-06 Compuware Corporation Byte code instrumentation
US6077311A (en) 1997-07-09 2000-06-20 Silicon Graphics, Inc. Method and apparatus for extraction of program region
US6317872B1 (en) 1997-07-11 2001-11-13 Rockwell Collins, Inc. Real time processor optimized for executing JAVA programs
US6016556A (en) 1997-07-17 2000-01-18 Tektronix, Inc. System for identifying an acquisition sample corresponding to a source code statement
US6282701B1 (en) 1997-07-31 2001-08-28 Mutek Solutions, Ltd. System and method for monitoring and analyzing the execution of computer programs
US6044461A (en) * 1997-09-16 2000-03-28 International Business Machines Corporation Computer system and method of selectively rebooting the same in response to a system program code update
US6338159B1 (en) 1997-12-12 2002-01-08 International Business Machines Corporation System and method for providing trace information
US6382846B1 (en) 1998-01-09 2002-05-07 Industial Technology Research Institute Intermediate instruction execution processor which resolves symbolic references without modifying intermediate instruction code
US6442663B1 (en) 1998-06-19 2002-08-27 Board Of Supervisors Of Louisiana University And Agricultural And Mechanical College Data collection and restoration for homogeneous or heterogeneous process migration
US6269367B1 (en) * 1998-06-30 2001-07-31 Migratec, Inc. System and method for automated identification, remediation, and verification of computer program code fragments with variable confidence factors
US6087967A (en) 1998-09-03 2000-07-11 International Business Machines Corporation Method for generating and reading a compressed all event trace file
US6289503B1 (en) * 1998-09-24 2001-09-11 International Business Machines Corporation System and method for trace verification
US6381735B1 (en) 1998-10-02 2002-04-30 Microsoft Corporation Dynamic classification of sections of software
US6274317B1 (en) 1998-11-02 2001-08-14 Millennium Pharmaceuticals, Inc. Automated allele caller
US6557168B1 (en) * 2000-02-25 2003-04-29 Sun Microsystems, Inc. System and method for minimizing inter-application interference among static synchronized methods
US6658416B1 (en) * 2000-07-10 2003-12-02 International Business Machines Corporation Apparatus and method for creating an indexed database of symbolic data for use with trace data of a computer program
US6708169B1 (en) * 2000-07-10 2004-03-16 International Business Machines Corporation Apparatus and method for generating a merged symbol file for verifying symbolic data
US6678883B1 (en) * 2000-07-10 2004-01-13 International Business Machines Corporation Apparatus and method for creating a trace file for a trace of a computer program based on loaded module information
US6766511B1 (en) * 2000-07-10 2004-07-20 International Business Machines Corporation Apparatus and method for performing symbolic resolution of modules using static representations of a trace
US6742178B1 (en) * 2000-07-20 2004-05-25 International Business Machines Corporation System and method for instrumenting application class files with correlation information to the instrumentation

Also Published As

Publication number Publication date
ATE375556T1 (de) 2007-10-15
EP1172729A3 (de) 2004-08-11
ES2291278T3 (es) 2008-03-01
EP1172729B1 (de) 2007-10-10
US6988263B1 (en) 2006-01-17
EP1172729A2 (de) 2002-01-16
DE60130840D1 (de) 2007-11-22

Similar Documents

Publication Publication Date Title
DE60130840T2 (de) Vorrichtung und Verfahren zur Katalogisierung von symbolischen Daten zur Verwendung bei der Leistungsanalyse von Computerprogrammen
DE10050684B4 (de) Verfahren und System zur periodischen Ablaufverfolgung für Aufrufsequenzen zwischen Routinen
DE69932371T2 (de) Verschiebbare Instrumentationskennzeichen für die Prüfung und die Fehlerbeseitigung eines Computerprogramms
DE60001916T2 (de) Plattformunabhängige speicherabbild analysearchitektur zur programmfehlerbeseitigung
DE60010420T2 (de) Automatisches Regressionstesten von Arbeitsplatz-Software
DE69909945T2 (de) Verfahren und Anordnung zur Korrelation von Profildaten dynamisch erzeugt durch ein optimiertes ausführbares Programm mit Quellcodeanweisungen
DE602004006947T2 (de) Plattformunabhängige Erzeugung einer einmaligen Kennung
DE19836333C2 (de) Software Installation und Testen für ein gemäß einer Bestellung gebautes Computersystem
DE69938218T2 (de) Vorrichtung und Verfahren zum Laden eines Java Anwendungsprogramms
DE69918334T2 (de) Erzeugung von kompilierten programmen für interpretative laufzeitumgebungen
US20060195823A1 (en) Memory debugging tool
DE19926116A1 (de) Mehr-Teilprozeß-Protokollierung in einer Konfigurationsdatenbank
DE19928980A1 (de) Codeerzeugung für einen Bytecode-Compiler
US6708169B1 (en) Apparatus and method for generating a merged symbol file for verifying symbolic data
DE10225664A1 (de) System und Verfahren zum Prüfen von Systemabrufereignissen mit Systemabrufumhüllungen
WO1994014117A1 (de) Verfahren zum testen mindestens einer klasse eines objektorientierten programmes auf einem rechner
Luckey et al. Reusing security requirements using an extended quality model
US6951011B1 (en) Diagnostic method and article for identifying significant events
DE112014002877T5 (de) Passives Überwachen von virtuellen Systemen mithilfe von agentenunabhängiger, echtzeitnaher Indexierung
US6289503B1 (en) System and method for trace verification
EP1384152B1 (de) Verfahren zur erfassung und aufzeichnung von systeminformationen und abläufen in verteilten nebenläufigen komponentenbasierten softwaresystemen
DE10393511T5 (de) Programmentwicklungsunterstützungsvorrichtung, Programmausführungsvorrichtung, Kompilierverfahren und Diagnoseverfahren
DE60213786T2 (de) System und verfahren zur automatischen erfassung von aussagen in einer java-kompatibilitätsprüfumgebung
Ziegenhagen et al. Using Developer-tool-Interactions to Expand Tracing Capabilities.
EP2587380B1 (de) Laufzeitumgebung und verfahren zur nichtinvasiven überwachung von softwareanwendungen

Legal Events

Date Code Title Description
8381 Inventor (new situation)

Inventor name: HUSSAIN, RIAZ Y., WINCHESTER, HAMPSHIRE, GB

Inventor name: JOHN, CHESTER CHARLES, WINCHESTER, HAMPSHIRE, GB

Inventor name: LEVINE, FRANK ELIOT, WINCHESTER, HAMPSHIRE, GB

Inventor name: RICHARDSON, CHRISTOPHER MICHAEL, WINCHESTER, H, GB

8320 Willingness to grant licences declared (paragraph 23)
8364 No opposition during term of opposition