DE19600428A1 - System und Verfahren zum Bestimmen eines tatsächlichen Arbeitssatzes eines Prozesses und Beziehen desselben auf Hochpegel-Datenstrukturen - Google Patents

Description

Die vorliegende Erfindung bezieht sich allgemein auf die Verwaltung von virtuellem Speicher in einer Mehrprogrammbe­ triebsumgebung und insbesondere auf ein System und ein Ver­ fahren zum Reduzieren von RAM-Anforderungen eines Arbeits­ satzes eines Prozesses.

Mit den Jahren wuchsen System-RAM-Anforderungen exponen­ tiell. Beispielsweise führten die ursprünglichen PDP-11-Mi­ nicomputer Unix mit nur 64 KBytes RAM aus. Solche frühe Workstations waren streng auf ein Maximum von 2 MBytes be­ grenzt. Heutzutage können Einstiegsmodell-Workstations mit 16 MByte schwerfällig erscheinen, wenn sie moderne Desktop- Software ausführen.

Ein herkömmlicher Lösungsansatz besteht darin, eine Spei­ cherabstimmung einfach als unnötig aufzugeben und zusätzli­ chen RAM hinzuzufügen. Immerhin fallen die RAM-Preise fort­ gesetzt. Jedoch fallen auch die Systempreise fortgesetzt. Bei den gegebenen relativen Verhältnissen der RAM-Anforde­ rungszunahmen, der RAM-Preisreduzierungen und der System­ preisreduzierungen stellt der RAM fortgesetzt einen signifi­ kanten Anteil der Systemkosten dar. Wenn ein Softwaresatz mehr RAM erfordert, und als solches ein aufwendigeres System erfordert als ein anderer Softwaresatz, kann außerdem in der heutigen Wettbewerbsumgebung der Verkauf des erstgenannten leiden.

Herkömmliche Lösungen richteten sich primär auf die Verbes­ serung von Seitenladungsalgorithmen (paging algorithms) vir­ tueller Speicher. Beispiele sind bei Gupta & Franklin, IEEE Transactions on Computers C-27: 706-712 (1978); Levy & Lip­ man, Computer 15: 35-41 (1982); und Loren & Deitel, Operating Systems, Addison-Wesley, Reading, MA (1981), zu finden. Ob­ wohl diese Verbesserungen dahingehend wichtig sind, daß sie ermöglichen, daß ein großes Programm effizienter abläuft, berücksichtigen dieselben das kontinuierliche Wachstum bei der Speicherbenutzung nicht. Somit fahren selbst mit dem weiterentwickeltsten Seitenladungsalgorithmus die System- RAM-Anforderungen fort, zuzunehmen, wenn die Prozesse fort­ fahren, zu wachsen.

Obwohl viel von diesem Extra-RAM durch eine zusätzliche Funktionalität verbraucht wird, wird jedoch viel desselben einfach als ein Ergebnis schlechter Programmierpraktiken verschwendet. Bemühungen zur Speicherabstimmung, die sich auf die Rückgewinnung des verschwendeten RAM richteten, ver­ wendeten verschiedene Techniken mit gemischtem Erfolg. Die Erfolglosigkeit wurde der Unfähigkeit dieser herkömmlichen Systeme zugeschrieben, der Speicherabstimmvorrichtung Kennt­ nis darüber zu vermitteln, woraus der Arbeitssatz eines spe­ ziellen Prozesses zusammengesetzt ist.

Es ist die Aufgabe der vorliegenden Erfindung, ein System und ein Verfahren zu schaffen, die ermöglichen, daß eine Speicherabstimmvorrichtung verschwendeten RAM zurückgewinnt, indem die RAM-Menge reduziert wird, die häufig durch einen Prozeß verwendet wird.

Diese Aufgabe wird durch ein System gemäß Patentanspruch 1 sowie ein Verfahren gemäß Patentanspruch 6 gelöst.

Die vorliegende Erfindung ist ein interaktives Informa­ tions-Protokollierungs- und Verarbeitungs-Werkzeug, das In­ formationen bezüglich der Datenstrukturbenutzung eines Pro­ zesses liefert. Diese Informationen werden verwendet, um den Arbeitssatz des dynamisch zugeordneten Speichers eines Pro­ zesses zu reduzieren. Die vorliegende Erfindung, die als AWS-Bestimmungsmittel (AWS = Actual Working Set = tatsächli­ cher Arbeitssatz) bezeichnet wird, verwendet für das vir­ tuelle Speicherproblem einen unterschiedlichen Lösungsan­ satz, indem der Speicherabstimmvorrichtung die notwendigen Informationen geliefert werden, um den Prozeß selbst zu ver­ bessern, und nicht das System zu verbessern, so daß ein ge­ gebener Prozeß effizienter arbeiten wird.

Die vorliegende Erfindung bestimmt, welche Abschnitte der häufig verwendeten, oder dynamisch zugeordneten, Seiten, die als der virtuelle Speicherarbeitssatz (VM; VM = Virtual Memory) (VWS; VWS = Virtual Memory Working Set), tatsächlich verwendet werden. Der tatsächliche Speicher, den ein Prozeß häufig verwendet, wird als der tatsächliche Arbeitssatz (AWS) des Prozesses bezeichnet.

Die vorliegende Erfindung bestimmt den tatsächlichen Ar­ beitssatz eines dynamisch zugeordneten Speichers für eine gegebene Bewertung (benchmark). Der elementare Lösungsansatz der AWS-Bestimmungseinrichtung 400 besteht darin, zu beo­ bachten, welche Datenstrukturen Seitenfehler bewirken, wenn der Zielprozeß schwerwiegend zeitverschwendend (thrashing) ist. Die vorliegende Erfindung weist eine Datenprotokollie­ rungseinrichtung und einen Datenanalysator auf. Die Daten­ protokollierungseinrichtung stellt sicher, daß eine konsi­ stente Bewertung erreicht wird, um die genauesten Ergebnisse zu erhalten, erhöht die Anzahl und die Granularität von Hal­ denseitenfehlern (heap page faults) für den Zielprozeß, um zu ermöglichen, daß der Seitenfehlermechanismus des Prozes­ sors zählt, wie oft auf die zugeordnete Datenstruktur zuge­ griffen wird, und protokolliert alle Haldenseiten-Fehler und -Transaktionen.

Der Datenanalysator ist ein interaktives Informationsverar­ beitungswerkzeug, das effizient die großen Datenmengen ver­ arbeitet, die während eines Bewertungslaufs durch die Daten­ protokollierungseinrichtung protokolliert werden. Der Daten­ analysator ermöglicht ferner, daß Benutzer interaktiv die verarbeiteten Daten erforschen, um Einblick in einen Hal­ den-AWS eines Prozesses zu erlangen. Der Datenanalysator korreliert jeden Block des Haldenspeichers mit einer spezi­ ellen C-Datenstruktur. Nachdem die Bewertung abgeschlossen ist und die oben genannten Informationen protokolliert und korreliert sind, wird danach ein Informationsverarbeitungs­ schritt durchgeführt, bei dem eine näherungsweise Bestimmung des Halden-AWS des Zielprozesses durchgeführt wird. Dieser Abschnitt beschreibt den allgemeinen Algorithmus zum Verar­ beiten der protokollierten und korrelierten Informationen.

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

Fig. 1 ein Systemblockdiagramm der bevorzugten Computerum­ gebung, in der die vorliegende Erfindung implemen­ tiert ist;

Fig. 2 ein Blockdiagramm der Beziehung zwischen einem phy­ sikalischen Speicher und einem virtuellen Speicher;

Fig. 3 ein Beispiel eines virtuellen Speichersystems, bei dem der virtuelle Speicher in einem System-RAM und einem sekundären Speicher gespeichert ist;

Fig. 4 ein Blockdiagramm eines virtuellen Arbeitssatzes (VWS) und eines tatsächlichen Arbeitssatzes (AWS) eines Prozesses;

Fig. 5 ein Funktionsblockdiagramm der Bestimmungseinrich­ tung des tatsächlichen Arbeitssatzes der vorliegen­ den Erfindung;

Fig. 6 ein Flußdiagramm des Datenprotokollierungsprozes­ ses, der durch die Datenprotokollierungseinrichtung der vorliegenden Erfindung durchgeführt wird;

Fig. 7 eine Tabelle von Seitenfehlerdaten, die während ei­ nes typischen Bewertungslaufes protokolliert wird;

Fig. 8 eine Tabelle von Halden-Transaktionsdaten, die wäh­ rend eines typischen Bewertungslaufes protokolliert werden;

Fig. 9 ein Flußdiagramm des Hochpegel-Datenanalyse-Prozes­ ses, der durch den Datenanalysator der vorliegenden Erfindung durchgeführt wird;

Fig. 10 eine Tabelle der Prozeduraufruf-Zurückverfolgungen zum Erzeugen von Fensterstrukturen;

Fig. 11 ein Flußdiagramm der Transaktionsverarbeitung, die durch den Datenanalysator der vorliegenden Erfin­ dung durchgeführt wird; und

Fig. 12 ein Flußdiagramm der Seitenfehlerverarbeitung, die durch den Datenanalysator der vorliegenden Erfin­ dung durchgeführt wird.

Das bevorzugte Ausführungsbeispiel der vorliegenden Erfin­ dung wird nun bezugnehmend auf die Figuren, in denen gleiche Bezugszeichen gleiche Elemente anzeigen, beschrieben.

I. Einführung

Die vorliegende Erfindung ist ein interaktives Informa­ tions-Protokollierungs- und -Verarbeitungs-Werkzeug, das In­ formationen bezüglich der Datenstrukturbenutzung eines Pro­ zesses liefert. Diese Informationen werden verwendet, um den Arbeitssatz des dynamisch zugeordneten Speichers eines Pro­ zesses zu reduzieren. Zuerst wird ein Systemüberblick gelie­ fert. Dann wird ein kurzer Rückblick auf die virtuelle Spei­ cher- und Arbeitssatz-Theorie geboten. Danach wird das be­ vorzugte Ausführungsbeispiel der vorliegenden Erfindung zum Identifizieren des tatsächlichen Arbeitssatzes des dynamisch zugeordneten Speichers eines Prozesses beschrieben. Schließ­ lich wird eine Fallstudie geliefert.

II. Systemüberblick

Fig. 1 ist ein Blockdiagramm eines Computersystems 100, in dem die vorliegende Erfindung vorzugsweise implementiert ist. Fig. 1 zeigt einen Unix-Systemkern, welcher verschiede­ ne Module und die Beziehungen derselben zueinander zeigt. Speziell zeigt Fig. 1 das Dateienteilsystem 102 und das Pro­ zeßsteuerteilsystem 104, die zwei Hauptkomponenten des Unix-Systemkerns 108. Fig. 1 dient als eine nützliche logi­ sche Ansicht des Unix-Systems, obwohl der Kern in der Praxis von dem Modell abweicht, da einige Module mit den inneren Operationen anderer in Wechselwirkung stehen.

Fig. 1 zeigt drei Ebenen des Computersystems 100: eine Be­ nutzerebene 106, eine Kernebene 108 und eine Hardwareebene 110. Die Systemaufrufschnittstelle 112 und die Bibliotheks- Schnittstelle 114 stellen die Grenze zwischen Anwendungspro­ grammen 116 und dem Kern 108 dar. Die Systemaufrufe sehen aus wie gewöhnliche Funktionsaufrufe in C-Programmen, wobei Bibliotheken diese Funktionsaufrufe auf Grundelemente abbil­ den, die notwendig sind, um das Betriebssystem zu betreten. Jedoch können Assemblersprachenprogramme verwendet werden, um Systemaufrufe direkt ohne eine Systemaufrufbibliothek aufzurufen. Programme verwenden häufig weitere Bibliotheken, beispielsweise die Standard-I/O-Bibliothek, um eine weiter­ entwickeltere Verwendung der Systemaufrufe zu liefern. Die Bibliotheken sind zur Kompilierungszeit mit den Programmen verbunden und sind folglich ein Teil der Anwendungsprogram­ me.

Fig. 1 unterteilt den Satz von Systemaufrufen in diejenigen, die mit dem Dateienteilsystem 102 in Wechselwirkung stehen, und diejenigen, die mit dem Prozeßsteuerteilsystem 104 in Wechselwirkung stehen. Das Dateienteilsystem 102 verwaltet Dateien, wobei es Dateiraum zuordnet, freien Raum verwaltet, den Zugriff auf Dateien steuert und Daten für die Benutzer wiedergewinnt. Prozesse stehen über einen spezifischen Satz von Systemaufrufen, die in der Technik gut bekannt sind, mit dem Dateienteilsystem 102 in Wechselwirkung.

Das Dateienteilsystem 102 greift unter Verwendung einer Puf­ fervorrichtung 118 auf Dateidaten zu, welche einen Datenfluß zwischen der Kernebene 108 und sekundären Speichervorrich­ tungen, die als sekundärer Speicher 138 gezeigt sind, re­ gelt. Die Puffervorrichtung 118 steht mit Block-I/O-Vorrich­ tungstreibern 124 (I/O = Input/Output = Eingabe/Ausgabe) in Wechselwirkung, um eine Datenübertragung zu und von dem Kern 108 zu initiieren. Die Vorrichtungstreiber sind Kernmodule, die den Betrieb von Peripherievorrichtungen steuern. Die Block-I/O-Vorrichtungen 124 sind Direktzugriffsspeichervor­ richtungen, oder alternativ bewirken die Vorrichtungstreiber derselben, daß sie dem Rest des Systems 100 als Direktzu­ griffsspeichervorrichtungen erscheinen. Beispielsweise kann ein Bandtreiber ermöglichen, daß der Kern 108 eine Bandein­ heit als eine Direktzugriffsspeichervorrichtung liest. Das Dateienteilsystem 102 steht ferner direkt mit "Roh-"I/O- Vorrichtungstreibern ohne das Eingreifen der Puffervorrich­ tung 118 in Wechselwirkung. Rohvorrichtungen, die manchmal als Zeichenvorrichtungstreiber 122 bezeichnet werden,
schließen alle Vorrichtungen ein, die nicht Blockvorrich­ tungstreiber 124 sind. Die meisten Blockvorrichtungen 124 liefern ferner eine Zeichenvorrichtungs-Typ-Schnittstelle, um ein Umgehen des Puffer-Cache 118 des Kerns zu umgehen. Dies wird als ein "Roh-I/O" zu einer Blockvorrichtung be­ zeichnet. Die Summe der Zeichenvorrichtungen 122 und der Block-I/O-Vorrichtungen 124 bildet die Vorrichtungstreiber 120.

Das Prozeßsteuerteilsystem 104 ist für eine Zwischenprozeß­ kommunikation 130, eine Speicherverwaltungseinrichtung 134 und eine Prozeß-Synchronisation und -Ablaufsteuerung (sche­ duling) 132 verantwortlich. Das Dateienteilsystem 102 und das Prozeßsteuerteilsystem 104 stehen in Wechselwirkung, wenn eine Datei zur Ausführung in den Speicher geladen wird, wobei das Prozeßsteuerteilsystem 104 ausführbare Dateien in den Speicher liest, bevor dieselben ausgeführt werden. Das Prozeßsteuerteilsystem 104 implementiert gut bekannte Sy­ stemaufrufe zum Steuern von Prozessen.

Das Speicherverwaltungsmodul 134 steuert die Zuordnung des Speichers. Wenn das System zu einer beliebigen Zeit nicht genug physikalischen Speicher für alle Prozesse aufweist, bewegt der Kern 108 dieselben zwischen einem primären Spei­ cher 136 und einem sekundären Speicher 138, so daß alle Pro­ zesse eine angemessene Chance erhalten, ausgeführt zu wer­ den. Es gibt im allgemeinen zwei Verfahrensweisen zum Ver­ walten von Speicher: Seiten-Ein/Auslagern (swapping) und be­ darfsweises Seitenladen (paging). Der Seiten-Ein/Auslage­ rungsvorrichtungs-Prozeß (swapper process) wird manchmal als die Ablaufsteuerung 132 bezeichnet, da er die Zuordnung des Speichers für die Prozesse "plant" und den Betrieb der CPU- Ablaufsteuerung beeinflußt.

Das Ablaufsteuerungsmodul 132 ordnet die CPU Prozessen zu. Es plant dieselben, um nacheinander zu laufen, bis dieselben die CPU freiwillig preisgeben, während sie auf ein Betriebs­ mittel warten oder bis der Kern dieselben unterbricht, wenn ihre jüngere Ablaufzeit ein Zeitquantum überschreitet. Die Ablaufsteuerung 132 wählt dann den in Frage kommenden Prozeß mit der höchsten Priorität, um ausgeführt zu werden; der ur­ sprüngliche Prozeß wird wieder ausgeführt, wenn er der ver­ fügbare, in Frage kommende Prozeß mit der höchsten Priorität ist. Es gibt mehrere Formen einer Zwischenprozeßkommunika­ tion 130, im Bereich einer asynchronen Signalisierung von Ereignissen bis zu einer synchronen Übertragung von Meldun­ gen zwischen Prozessen.

Schließlich ist die Hardwaresteuerung 140 für die Handhabung von Unterbrechungen und für die Kommunikation mit der Hard­ wareebene 110 verantwortlich. Die Hardwareebene 110 weist einen Prozessor 142, einen Systemspeicher oder primären Speicher 136 und einen Systembus 144 auf. Der primäre Spei­ cher 136 ist vorzugsweise ein Direktzugriffsspeicher (RAM; RAM = Random Access Memory).

Eine geeignete Art des Prozessors 142 ist die gut bekannte RISC-System/6000-Familie von Computern, die von IBM herge­ stellt wird. Vorzugsweise ist der Prozessor 142 ein Hew­ lett-Packard-PA-RISC-System. Es sollte jedoch erwähnt wer­ den, daß alternativ andere Computer verwendet werden können, ohne vom Bereich und vom Geist der vorliegenden Erfindung abzuweichen.

Die Hardwareebene 110 weist ferner eine Anzahl von Periphe­ rievorrichtungen auf, die an einem I/O-Bus 146 angebracht sind, einschließlich eines Sekundärspeichers 138, einer An­ zeigevorrichtung 148 und Benutzerschnittstellenvorrichtungen 150, wie z. B. einer Tastatur oder Vorrichtungen des Maus- Typs. Der Sekundärspeicher 138 weist beispielsweise ein Festplattenlaufwerk und/oder ein Diskettenlaufwerk auf. Außerdem kann eine Aufzeichnungs/Wiedergabe-Vorrichtung 152 verwendet sein, um Benutzereingaben zu der Benutzerschnitt­ stelle 150 und der Anzeigevorrichtung 148 aufzuzeichnen und diese dann direkt durch den I/O-Bus 146 wiederzugeben. Vor­ richtungen, beispielsweise Platten oder Endvorrichtungen können die CPU unterbrechen, während ein Prozeß ausgeführt wird. Wenn dies der Fall ist, kann der Kern die Ausführung des unterbrochenen Prozesses wieder aufnehmen, nachdem die Unterbrechung abgewickelt wurde. Unterbrechungen werden nicht durch spezielle Prozesse abgewickelt, sondern durch spezielle Funktionen in dem Kern, die im Zusammenhang mit dem momentan laufenden Prozeß aufgerufen werden.

Eine geeignete Form eines Kerns 108 ist das gut bekannte und allgemein verwendete Unix-System, beispielsweise das AT Unix System V, hergestellt von AT Bell Laboratories, Murray Hill, New Jersey, USA, und das Berkeley Software Distribution (BSD) Unix System, hergestellt von der Univer­ sity of California at Berkeley, Berkeley, Kalifornien, USA.

Varianten dieser Unix-Systeme sind verfügbar, die für eine spezifische Anwendung oder Maschine konfiguriert sind. Eine solche Konfiguration weist das Hewlett-Packard-HP-UX-Unix- Betriebssystem der bevorzugten Implementierungen, erhältlich von Hewlett Packard, Fort collins, Colorado, USA, auf.

III. Virtueller Speicher und das herkömmliche Arbeitssatzmodell

Das Computersystem 100 ist ein virtuelles Speichersystem. Fig. 2 zeigt die Beziehung zwischen einem physikalischen Speicher und einem virtuellen Speicher. In Fig. 2 ist der physikalische Speicher in dem primären Speicher 136 als phy­ sikalische Seiten 202 gezeigt. Ein virtuelles Speichersystem (VM-System) vermittelt Computerprozessen die Illusion, daß der primäre Speicher 136 eine Kapazität aufweist, um eine größere Anzahl von physikalischen Seiten 202 zu halten, als es tatsächlich der Fall ist. Folglich kann jeder Prozeß, der in dem Computersystem 100 abläuft, einen virtuellen Adreß­ raum 204 aufweisen, der viel größer als die Menge des physi­ kalischen Speichers (RAM) in dem Primärspeicher 136, der in das System eingebaut ist, ist. VM-Systeme vermitteln diese Illusion auf eine komplizierte Art und Weise.

Sowohl die virtuellen als auch die physikalischen Adreßräume sind in kleinere Komponenten 206 aufgeteilt, die Seiten ge­ nannt werden. Seiten 206 weisen typischerweise eine Größe von wenigen KBytes auf. Jede Seite befindet sich entweder in einem RAM (primärer Speicher 136) oder in einem Ein/Auslage­ rungs-Raum (swap space) 206, beispielsweise dem sekundären Speicher 138. Die Speicherverwaltungseinrichtung 134 enthält eine Abbildung zwischen jeder virtuellen Seite 208 und ihrem tatsächlichen Standort. Ein Teil dieser Abbildung ist in ei­ ner speziellen Speicherverwaltungshardware in der CPU 142 gespeichert. Jeder Zugriff auf den virtuellen Speicher läuft durch diese Speicherverwaltungshardware. Wenn sich die Spei­ cherortseite in dem RAM 136 befindet, wird die korrekte phy­ sikalische Adresse in dem physikalischen Speicher 202 für den Speicherzugriff verwendet. Wenn sich die virtuelle Spei­ cherortseite in dem Ein/Auslagerungs-Raum 206 befindet, tritt ein Seitenfehler auf, wodurch das Bild in den RAM 136 geladen wird, bevor der Speicherzugriff stattfindet.

Wenn der RAM 136 voll ist, bevor eine Seite in den RAM ge­ bracht wird, muß eine andere Seite in den Ein/Auslagerungs- Raum 206 gesendet werden. D.h., daß die gegenwärtig residen­ te Seite "ausgeladen" ("paged out") oder "ausgelagert" ("swapped out") wird. Die Speicherverwaltungseinrichtung 134 versucht, eine angemessene Verfahrensweise zu verwenden, um zu bestimmen, welche Seite 210 ausgelagert werden soll.

Im allgemeinen ist die Zeit, um die Seitenladungs-Aktivität, die oben beschrieben wurde, durchzuführen, relativ zu der Verarbeitungsgeschwindigkeit des Prozessors 142 lang. Die genaue Zeit wird von verschiedenen Faktoren abhängen, bei­ spielsweise den relativen Geschwindigkeiten der Ein/Ausla­ gerungs-Platte und des Computers, wird jedoch so lang sein, daß, wenn ein Prozeß einen Seitenfehler ergibt, derselbe ausgesetzt wird, bis nachdem die Seite in den RAM 136 ge­ bracht wurde.

Wenn das Computersystem 100 beispielsweise einen RAM 136 von 64 KByte physikalischen Speicher 202 aufweist, wobei jede Seitengröße 4 KByte ist, weist das System 16 Seiten physika­ lischen Speicher 202 auf. Wenn ein Prozeß 128 KByte virtuel­ len Speicher verwendet, wird es 32 Seiten virtuellen Spei­ cher aufweisen. Wenn sich die ersten 16 Seiten des Prozesses gegenwärtig im RAM 136 befinden, wenn der Prozeß auf eine Adresse in der 17. Seite zugreifen will, erhält die Spei­ cherverwaltungseinrichtung 134 auf den Zugriff in der 17. Seite hin einen Seitenfehler. Um die 17. Seite aus dem Ein/Auslagerungs-Raum 206 einzuladen (page in), muß eine der ersten 16 Seiten aus dem RAM 136 in den Ein/Auslagerungs- Raum 206 ausgelagert werden.

Wenn der Prozeß den Großteil seiner Speicherzugriffe in den gleichen 16 Seiten hält, wird er selten einen Seitenfehler erhalten und somit ein exzellentes Verhalten aufweisen. Wenn der Prozeß jedoch in einer zyklischen Form (round-robin fa­ shion) auf alle 32 Seiten zugreift, wird er die meiste Zeit ausgesetzt sein. Ein Prozeß wird als zeitverschwendend (thrashing) bezeichnet, wenn dies der Fall ist. Wenn die meisten aktiven Prozesse ein übermäßiges Seitenladen erfah­ ren, wird das System als zeitverschwendend bezeichnet. Ein kleiner sichtbarer Fortschritt findet statt, da die "akti­ ven" Prozesse die meiste Zeit ausgesetzt sind.

Moderne Mehrprogrammbetrieb-Betriebssysteme, beispielsweise das HP-UX-Betriebssystem des bevorzugten Ausführungsbei­ spiels, verwenden komplizierte virtuelle Speicherverwal­ tungssysteme. Da der Kern versucht, mehrere Prozesse zur gleichen Zeit zeitlich zu verschachteln, opfert er erstens selten den gesamten RAM des Computers für einen Prozeß. Der RAM wird virtuelle Seiten von mehreren Prozessen enthalten. Zweitens verwenden moderne Kerne hochentwickelte Algorith­ men, um die Anzahl von Seitenfehlern zu reduzieren. Wenn be­ stimmte Seitenfehler auftreten, wird der HP-UX-Kern bei­ spielsweise bestimmen, wenn umgebende Seiten gleichzeitig eingebracht werden sollen, in dem Fall, in dem bald auf die­ selben zugegriffen werden wird. Der Kern hält ferner ver­ schiedene Maßgaben, um zu bestimmen, welche Seite ausgela­ gert werden soll (d. h. diejenigen, die wahrscheinlich nicht bald wieder hereingebracht werden sollen). Ein Kern will niemals Speicher in einem Arbeitssatz eines Prozesses aus­ laden.

Das Arbeitssatzmodell, das von Denning (Denning, P.J., Com­ munications of the ACM 11: 323-333 (1968); Denning, P.J., IEEE Transactions on Software Engineering SE-6: 64-84 (1980)), eingeführt wurde, hilft dabei, die VM-Aktivität in einem Mehrprogrammbetrieb-Betriebssystem zu verstehen. Die elementare Idee, die das Arbeitssatzmodell stützt, besteht darin, daß ein Prozeß häufig auf einen Teilsatz seiner Sei­ ten zugreifen wird. Diese Seiten werden als der Arbeitssatz des Prozesses bezeichnet. Die Arbeitssatzseiten müssen resi­ dent bleiben, damit der Prozeß nicht zeitverschwendend wird.

Ein Arbeitssatz eines Prozesses wird dazu tendieren, sich mit der Zeit zu ändern. Beispielsweise kann ein Arbeitssatz eines Prozesses zur Anlaufzeit viel größer und völlig unter­ schiedlich zu dem Arbeitssatz des Prozesses im stabilen Zu­ stand sein. Ferner kann sich der Arbeitssatz eines Menü-be­ triebenen Programmes ändern, wenn ein Benutzer unterschied­ liche Menüpunkte wählt.

Wenn die virtuellen Speichergrößen aller Prozesse in den verfügbaren RAM passen, werden Seitenfehler nur auftreten, wenn ein Prozeß zum ersten Mal auf eine Seite zugreift. In solchen Fällen wird das Systemverhalten nicht unter einer Zeitverschwendung leiden.

Eine Zeitverschwendung tritt auf, wenn die Summe der Ar­ beitssätze aller aktiven Prozesse den verfügbaren RAM über­ schreitet. In solchen Fällen muß, um einen Arbeitssatz eines Prozesses einzuladen, der Arbeitssatz eines anderen Prozes­ ses ausgeladen werden.

Wenn ein Kern erfaßt, daß ein Prozeß zeitverschwendend ist, kann der Kern beginnen, drastische Maßnahmen zu ergreifen. Beispielsweise kann ein Kern ganze Prozesse auslagern, um die Anzahl der verfügbaren Seiten für den (die) verbleibenden Prozess(e) zu erhöhen. Selbstverständlich müssen, wenn die ausgelagerten Prozesse schließlich wiederum laufen sollen, alle Arbeitssatzseiten derselben wiederum eingebracht wer­ den, wobei bewirkt wird, daß andere Prozesse ausgelagert werden. Wie oben erläutert wurde, wurden verschiedene Ver­ besserungen zu den VM-Seitenladungs-Algorithmen vorgeschla­ gen, um das Gesamtsystemverhalten zu erhöhen und die Wahr­ scheinlichkeit und die ungünstigen Auswirkungen des Zeitver­ schwendens zu reduzieren. Jedoch berücksichtigen, wie oben erläutert wurde, diese Verbesserungen nicht das kontinuier­ liche Wachstum der Speicherbenutzung.

IV. Bestimmen des tatsächlichen Arbeitssatzes (AWS) A. Arbeitssatzmodell der vorliegenden Erfindung

Bei der obigen Erläuterung wurde der Ausdruck "Arbeitssatz" verwendet, um spezifisch Seiten 204 des virtuellen Speicher­ systems zu bezeichnen. Dies gilt primär aufgrund der her­ kömmlichen Richtung der virtuellen Speicherverbesserung. Herkömmlicherweise konzentrierten sich die Verbesserungen auf die Seitenladungs-Funktionen, die durch die Speicherver­ waltungseinrichtung 134 durchgeführt werden. Dies ist höchstwahrscheinlich das Ergebnis der residenten Prozesse, die durch andere Hersteller als die, die das Betriebssystem erzeugen, erzeugt werden. Die vorliegende Erfindung ist je­ doch ein System und ein Verfahren, die auf das Verbessern des Prozesses selbst und nicht auf das Verbessern der Spei­ cherverwaltungseinrichtung 134 gerichtet sind, so daß ein gegebener Prozeß effizienter arbeiten wird. Um diese unter­ schiedliche Perspektive und diesen Lösungsansatz aufzuneh­ men, müssen die herkömmlichen Definitionen, die in der In­ dustrie verwendet werden, adressiert werden.

Bezugnehmend auf Fig. 3 wird offensichtlich, daß das Abstim­ men des Nicht-Arbeitssatz-Speichers das Systemverhalten nicht verbessern wird. Es sei beispielsweise, bezugnehmend auf das oben gegebene Beispiel und bezugnehmend auf Fig. 3, angenommen, daß der Arbeitssatz siebzehn Seiten groß ist (beispielsweise die Seiten 1 bis 17), während die gesamte Größe des Prozesses noch 32 Seiten ist. Wiederum weist der Systemspeicher 136 nur sechzehn Seiten auf. Gemäß dem her­ kömmlichen Arbeitssatzmodell wird das Computersystem 100 zeitverschwendend sein. Wenn eine Speicherabstimmbemühung 8 Seiten, die nicht im Arbeitssatz sind (beispielsweise die Seiten 25 bis 32), wegschneidet, wird das System 100 noch zeitverschwendend sein. Dies ist der Fall, da keine der be­ seitigten Seiten in dem Arbeitssatz war. Folglich wird der Computer 100 noch zeitverschwendend sein, obwohl ein Viertel der Prozeßseiten abgeschnitten wurde. Wenn statt dessen eine der Arbeitssatzseiten abgeschnitten wird (beispielsweise Seite 17), wird der Computer nicht länger zeitverschwendend sein.

Bezugnehmend auf Fig. 4 wird nun die Definition eines Pro­ zeßarbeitssatzes gemäß der vorliegenden Erfindung beschrie­ ben. Aus der Perspektive der Speicherverwaltungseinrichtung 134 kann eine gesamte Seite 402 im Arbeitssatz eines Prozes­ ses sein, wobei das Programm jedoch nur einen kleinen Teil dieser Seite verwenden kann. Folglich werden bei der vorlie­ genden Erfindung die häufig verwendeten oder dynamisch zuge­ ordneten Seiten als der virtuelle Speicher- (VM) Arbeitssatz (VWS) des Prozesses 404 bezeichnet.

Der tatsächliche Speicher, den ein Prozeß häufig verwendet, wird als der tatsächliche Arbeitssatz (AWS) 406 des Prozes­ ses bezeichnet. Da eine Speicherabstimmung typischerweise unter Verwendung von Hochpegel-Sprachen, beispielsweise C und Fortran, durchgeführt wird, ist der AWS 406 in Form von Prozeduren und Datenstrukturen ausgedrückt. Der VWS 404 (der herkömmliche Arbeitssatz) ist in Form von Seiten ausge­ drückt. D.h., daß die Datenstruktur oder der Code einen kleinen Abschnitt 406 einer speziellen Seite verwenden kön­ nen.

In den meisten Situationen wird der AWS 406 stets kleiner als der VWS 404 sein. Der Grund dafür sind Unterschiede der Granularität. Die Granularität des AWS 406 kann in Byte ge­ messen werden, wohingegen der VWS 404 stets in der Größe je­ der Seite (typischerweise einige wenige KByte) gemessen wird. Die vorliegende Erfindung verwendet diesen Größenun­ terschied, um zu bestimmen, welcher Teil des virtuellen Speicherarbeitssatzes 404 in dem tatsächlichen Arbeitssatz 406 eingeschlossen ist.

Bezugnehmend auf das Beispiel, das oben bezüglich Fig. 3 be­ schrieben wurde, sei angenommen, daß der VWS 404 siebzehn Seiten aufweist, der Programmcode eine einzelne Seite (bei­ spielsweise die erste Seite) besetzt, und das Programm kon­ stant auf zwei Sätze von Variablen zugreift. Es sei ferner angenommen, daß der erste Satz grob gesprochen die Hälfte der zweiten Seite besetzt, und der zweite Satz eine verket­ tete 16-Element-Liste ist, wobei jede Elementgröße 24 Byte beträgt, wobei sich jedes Element in einer unterschiedlichen Seite befindet, beginnend mit der verbleibenden Hälfte der zweiten Seite.

Bei diesem speziellen Fall betrachtet die vorliegende Erfin­ dung nur diejenigen Abschnitte des VWS 404, die tatsächlich als der AWS 406 verwendet sind. Die speziellen Datenstruktu­ ren, auf die bei diesem Beispiel häufig zugegriffen wird, sind relativ sehr klein. Der AWS 404 ist entsprechend klein. Diese Informationen ermöglichen es, das Programm sorgfältig zu entwerfen, derart, daß sich die verkettete Liste nur in der zweiten Seite befindet. In einem solchen Fall wird der VWS 404 gerade zwei Seiten groß sein, und nicht 17 Seiten. Dies ist näher an der Größe des AWS 406.

B. Bevorzugter Speicherabstimmprozeß

Die Speicherabstimmung wird als der Prozeß des Reduzierens des VWS eines Prozesses betrachtet. Wenn diese auf einem Prozeß durchgeführt wird, der zu einer Zeitverschwendung beiträgt, wird die Zeitverschwendung reduziert oder besei­ tigt, abhängig davon, wie groß die durchgeführte Reduzierung ist. Typischerweise wird die Speicherabstimmung allgemein als eine oder mehrere der folgenden Aufgabentypen durchfüh­ rend beschrieben: (1) Verbessern der Lokalität; (2) Reduzie­ ren einer Haldenfragmentierung; (3) Beseitigen von Speicher­ lecks; (4) Reduzieren der Größe von Code- und Daten-Struktu­ ren; (5) Wiederverwenden des Speichers; und (6) Planen des Arbeitssatzwachstums.

Bezüglich der Verbesserung der Lokalität machen Posten, auf die häufig zugegriffen wird, die relativ klein sind und sich in unterschiedlichen Seiten befinden, den VWS unnötig groß (wie in dem obigen einfachen Beispiel). Wenn es möglich ist, hat das Zuordnen der Posten nebeneinander einen kleineren VWS (näher an der Größe des AWS) und weniger Seitenfehler zur Folge. Diese Regel gilt sowohl für einen Code als auch für Daten. Beispielsweise kann das Gruppieren von häufig verwendeten Prozeduren den AWS des Codes reduzieren. Einige Compiler (z. B. der Compiler, der HP-UX zugeordnet ist), hel­ fen, diese Aufgabe für den Code zu automatisieren.

Eine Haldenfragmentierung tritt auf, wenn der Speicher in Mustern zugeordnet und freigemacht wird, die unbenutzte Lö­ cher in der Halde belassen. Die Fragmentierung reduziert die Lokalität des AWS, wodurch unnötigerweise der VWS vergrößert wird.

Ein Speicherleck tritt auf, wenn ein Stück eines zugeordne­ ten Speichers nicht länger verwendet ist, jedoch nicht frei­ gemacht ist. Speicherlecks reduzieren ebenfalls die Lokali­ tät des AWS, wodurch unnötigerweise der VWS vergrößert wird.

Der Zweck des Reduzierens der Größe von Code- und Daten- Strukturen besteht darin, den AWS und den VWS zu schrumpfen. Wenn eine Struktur beispielsweise mehrere 32-Bit-Felder für jeden mehrerer boolscher Werte enthält, kann dieselbe statt dessen eine Gruppe von 1-Bit-Feldern verwenden. Manchmal können 16-Bit-Integer-Felder für 32-Bit-Integerzahlen er­ setzt werden. Manchmal können wenig häufig verwendete Codes- Daten aus der Mitte der häufig verwendeten Codes/Daten her­ ausgezogen werden (beispielsweise WindowoptRec des X-Ser­ vers).

Das Wiederverwenden von Speicher verbessert das Systemver­ halten. Es sei beispielsweise angenommen, daß eine Prozedur einen oder mehrere temporäre Posten zuordnet, jedesmal, wenn sie aufgerufen wird, dieselben verwendet und danach frei macht. Durch das einmalige Zuordnen der Posten und das in der Umgebung Halten derselben für die Zukunft, kann die Fragmentierung der Halde reduziert werden (was die Lokalität für andere haldenartig angeordnete Datenstrukturen verbes­ sert).

Das Planen des Arbeitssatzwachstums verbessert ebenfalls das Systemverhalten. Beispielsweise ist der VWS eines Prozesses häufig zur Anlaufzeit sehr groß. Das Hochfahren mehrerer Prozesse zur gleichen Zeit kann eine temporäre Zeitver­ schwendungssituation zur Folge haben. Durch die Synchronisa­ tion des Beginnens der Prozesse wird die Summe der Arbeits­ sätze nicht groß genug werden, um eine Zeitverschwendung zu bewirken. Dies ist ein Beispiel auf Systemebene, wobei je­ doch ähnliche Beispiele innerhalb eines Codes gefunden wer­ den können.

Um die obigen Verbesserungen effektiv zu erhalten, bestimmt die vorliegende Erfindung einen Prozeß-AWS, der in den Hoch­ pegel-Sprach-Prozeduren und -Datenstrukturen ausgedrückt ist, mit denen der Prozeß geschrieben ist. Wie oben einge­ führt wurde, führt die vorliegende Erfindung Datenprotokol­ lierungs- und Datenanalyse-Funktionen durch. Fig. 5 ist ein Blockdiagramm des bevorzugten Ausführungsbeispiels der vor­ liegenden Erfindung. Bezugnehmend auf Fig. 5 weist die vor­ liegende Erfindung, die als eine AWS-Bestimmungseinrichtung 500 bezeichnet ist, eine Datenprotokollierungseinrichtung 502 und einen Datenanalysator 504 auf.

V. Tatsächlicher Arbeitssatz

Wie oben erwähnt wurde, bestimmt die vorliegende Erfindung den tatsächlichen Arbeitssatz eines dynamisch zugeordneten Speichers für eine gegebene Bewertung. Das bevorzugte Aus­ führungsbeispiel der vorliegenden Erfindung befindet sich in einer Unix-Umgebung. Folglich wird der dynamische zugeordne­ te Speicher als die Prozeßhalde bezeichnet.

Der elementare Lösungsansatz der AWS-Bestimmungseinrichtung 500 besteht darin, zu beobachten, welche Datenstrukturen zeitverschwendend ist. Dies ermöglicht es, zu bestimmen, welche Datenstrukturen häufig durch einen Prozeß verwendet werden. Fig. 5 ist ein Blockdiagramm der AWS-Bestimmungsein­ richtung 500 der vorliegenden Erfindung. Wie in Fig. 5 ge­ zeigt ist, weist die AWS-Bestimmungseinrichtung 500 eine Da­ tenprotokollierungseinrichtung 502 und einen Datenanalysator 504 auf. Die AWS-Bestimmungseinrichtung 500 wird spezifisch im Zusammenhang mit der Programmiersprache C erläutert, wo­ bei der ADM-Prozeß auf eine beliebige Programmiersprache an­ gepaßt und angewendet werden kann.

A. Datenprotokollierungseinrichtung 502

Die Datenprotokollierungseinrichtung 502 protokolliert Daten während Bewertungsdurchläufen für eine spätere Analyse durch die Datenverwaltungseinrichtung 504.

Fig. 6 zeigt ein grobes Flußdiagramm des ADM-Verfahrens, das durch die Datenprotokollierungseinrichtung 502 der vorlie­ genden Erfindung durchgeführt wird. Wie in Fig. 6 gezeigt ist, besteht der Datenprotokollierungsprozeß 600 aus den folgenden Schritten.

Der Datenprotokollierungsprozeß 600 beginnt bei "Beginne Da­ tenprotokollierung" 602. Wie detailliert nachfolgend be­ schrieben wird, wird der Datenprotokollierungsprozeß 600 als Teil eines vom Benutzer aufgerufenen Bewertungslaufs aufge­ rufen.

Sobald er aufgerufen ist, besteht der erste Schritt, der durch die Datenprotokollierungseinrichtung 502 durchgeführt wird, darin, Funktionen durchzuführen, die sicherstellen, daß eine konsistente Bewertung erhalten wird. Um die genaue­ sten Ergebnisse zu erhalten, muß die Datenprotokollierungs­ einrichtung 502 während mehreren Bewertungsläufen implemen­ tiert sein, während denen der gleiche Satz von Prozessen folgerichtig und wiederholt ausgeführt wird, wobei jeweils die gleichen Operationen während aufeinanderfolgender Bewer­ tungsläufe durchgeführt werden. Folglich wird während eines Schritts 604 ein Benutzer-interaktiver Lösungsansatz verwen­ det, um zu ermöglichen, daß der Benutzer die Prozesse und darauf bezogene Parameter für jeden Bewertungslauf auswählt. Je größer die Wiederholbarkeit der Bewertung ist, desto größer ist die Genauigkeit des Datenanalysators 404 beim Vergleichen der Ergebnisse jeder Bewertung.

In einem Schritt 606 wird die Anzahl und die Granularität der Haldenseitenfehler für den Zielprozeß maximiert. Granu­ larität bezieht sich auf die Anzahl der Datenstrukturen pro Seite. Dies ermöglicht es, daß die vorliegende Erfindung den Seitenfehlermechanismus des Prozessors verwendet, um zu zäh­ len, wie oft auf die zugeordnete Datenstruktur zugegriffen wird. Das bevorzugte und alternative Verfahren zum Erreichen dieser Erhöhung der Haldenseitenfehler ist detailliert nach­ folgend beschrieben. Sobald der Zielprozeß ausgewählt und eine wiederholbare Bewertung sichergestellt ist, wird in ei­ nem Schritt 608 die Bewertung (benchmark) aufgerufen.

In einem Schritt 610 wird eine zeitlich geordnete, zeitlich gestempelte Liste aller Haldenseitenfehler aufgebaut und im sekundären Speicher 140 gespeichert. Diese Liste enthält al­ le relevanten Informationen für jeden Seitenfehler zur zu­ künftigen Verwendung durch den Datenanalysator 504.

In einem Schritt 612 wird eine zeitlich geordnete, zeitlich gestempelte Liste aller Haldentransaktionen aufgebaut. Bei der Unix-Umgebung des bevorzugten Ausführungsbeispiels schließt dies Transaktionen ein, wie beispielsweise die Auf­ rufe malloc(), calloc(), realloc(), und free(). Diese Liste enthält alle relevanten Informationen für jede Transaktion, einschließlich der zugeordneten Größe, der zugeordneten Adresse, der freien Adresse und der Prozeduraufruf-Zurück­ verfolgung.

Jeder dieser Schritte wird nachfolgend detaillierter erläu­ tert.

1. Konsistente Bewertungsläufe

Wie oben bezüglich Schritt 604 erwähnt wurde, ist, um den Fortschritt eines beliebigen Speicherabstimmprojekts objek­ tiv zu messen, eine konsistent wiederholbare Bewertung er­ forderlich. Die Bewertungen der vorliegenden Erfindung un­ terscheiden sich von den herkömmlichen Bewertungstypen. Vie­ le Bewertungen behandeln einen oder zwei Prozesse. Anderer­ seits umfassen die Bewertungen, die im Schritt 604 erzeugt werden, eine Vielzahl von Prozessen, die stets die gleichen Operationen in der gleichen Zwischenprozeßreihenfolge durch­ führen. Dies minimiert Seitenfehlerschwankungen von Lauf zu Lauf.

Bei einem bevorzugten Ausführungsbeispiel kann eine aufge­ zeichnete Benutzersitzung als eine Bewertung dienen. Eine Aufzeichnungs/Wiedergabe-Vorrichtung 152 zeichnet Benutzer­ eingaben an der Anzeigevorrichtung 148 und der Benutzer­ schnittstelle 150 auf. Das Wiedergabewerkzeug gibt dann die Sitzung sehr exakt wieder. Alle Benutzereingabe- und X-Ser­ ver-Ereignisse müssen zeitlich gut gesteuert sein, was er­ fordert, daß die Abspiel-Wiedergabevorrichtung 152 das Kun­ denverhalten aktiv überwacht, und nicht nur passiv Eingaben zu dem X-Server sendet.

Die Anforderung, Seitenfehler zu maximieren, trägt zu einer anspruchsvollen Wiedergabeumgebung und zu einer schlechten Aufzeichnungsumgebung bei. Daher muß die Bewertungsaufzeich­ nung durchgeführt werden, wenn wenig Seitenfehler auftreten, während die Wiedergabe durchgeführt werden muß, wenn viele Seitenfehler auftreten. Die Aufzeichnungs/Wiedergabe-Vor­ richtung 152, die eine Sitzung genau wiedergibt, wenn das Bewertungssystem schwerwiegend zeitverzögernd war, ist je­ doch konfiguriert, um die Sitzung so schnell wie möglich wiederzugeben, wobei Lücken in der Benutzereingabe kompri­ miert werden, und wobei die Reihenfolge der Zwischenprozeß­ aktionen bewahrt wird.

2. Maximieren von Seitenfehlern

Das Maximieren der Anzahl und der Granularität von Seiten­ fehlern erhöht die Genauigkeit der AWS-Bestimmungseinrich­ tung 500, welche ihre Bestimmungen basierend auf beobachte­ ten Seitenfehlern durchführt. Wenn wenig Seitenfehler beob­ achtet werden, existieren wenig Daten, die zur Verarbeitung durch den Datenanalysator 504 erzeugt werden. Bei dem bevor­ zugten Ausführungsbeispiel der Erfindung werden Seitenfehler als der Mechanismus verwendet, um die Frequenz eines Zu­ griffs auf Datenstrukturen zu messen. Seitenfehler wurden gewählt, da es gegenwärtig existierende Kerne gibt, die Sei­ tenfehlerinformationen, die gespeichert werden sollen, aus­ werten.

Obwohl, wie oben bemerkt wurde, die besten Ergebnisse erhal­ ten werden, wenn eine einzelne Datenstruktur eine Seite be­ setzt, besetzen in vielen Fällen mehrere Datenstrukturen die gleiche Seite. Wenn bei einer derartigen Seite nur einmal ein Fehler auftritt, ist nur eine Struktur zu sehen und der Rest wird verdeckt sein. Je öfter eine Seite ein- und aus­ gelagert wird, desto größer ist die Wahrscheinlichkeit, daß diese Deckstrukturen zu sehen sind.

Es sei beispielsweise angenommen, daß zwei Datenstrukturty­ pen, auf die häufig zugegriffen wird, A und B, beide durch den gesamten Speicher verteilt sind (d. h., daß dieselben ei­ ne schlechte Lokalität aufweisen). Es sei ferner angenommen, daß für eine spezielle Bewertung diese Datenstrukturtypen den gleichen Satz von Seiten besetzen. Wenn die Seitenfehler nicht maximiert sind, können abhängig von den Zugriffsmu­ stern der Bewertung unterschiedliche Szenarien auftreten. Beispielsweise werden beide Strukturtypen die Fehler für ih­ re gemeinsam verwendeten Seiten teilen. Augenscheinlich wird einer der beiden alle Fehler verbrauchen. Eine weitere Mög­ lichkeit besteht darin, daß andere Strukturen alle Fehler verbrauchen.

Diese Szenarien verdecken Datenstrukturtypen, wodurch ver­ hindert wird, daß deren Auftreten durch die Datenprotokol­ lierungseinrichtung 502 protokolliert wird.

Bei dem bevorzugten Ausführungsbeispiel besetzt nur eine Struktur jede Seite. Wenn diese Seiten stets bald nach ihrer Verwendung ausgelagert werden, wird die Anzahl der Fehler, die diese Strukturen empfangen, anzeigen, wie häufig diesel­ ben verwendet werden. Es sei beispielsweise angenommen, daß zwei Strukturen, C und D, jeweils während eines schwachen Seitenladens gerade einen Seitenfehler empfangen, wobei je­ doch während eines starken Seitenladens C zwei Seitenfehler empfängt und D zwanzig empfängt. Es ist offensichtlich, daß D häufiger verwendet wird als C.

Mehrere Lösungsansätze können die Anzahl und die Granulari­ tät der Seitenfehler während eines Bewertungslaufs 508 er­ höhen. Am einfachsten ist es, die System-RAM-Menge 136 zu reduzieren. Die einfachste Art und Weise, dies zu tun, be­ steht darin, das System abzuschalten und herauszuziehen (SIMMs). Jedoch kann dies zeitaufwendig sein und wird wahr­ scheinlich keine ausreichende Granularität ergeben, um immer dichter an die optimale Menge von Seitenfehlern heranzukom­ men. Die optimale Anzahl von Seitenfehlern ist ausreichend, daß eine relativ genaue AWS-Bestimmung durchgeführt werden kann, jedoch nicht so groß, daß die Bewertungsläufe unan­ nehmbar lang werden. Ein bevorzugter Lösungsansatz besteht darin, einen verbesserten Kern 108 zu verwenden, der es er­ möglicht, daß ein Benutzer in relativ kleinen Inkrementen die RAM-Menge 136 spezifiziert, für die der Kern 108 pro­ grammiert ist, um auf dieselbe zuzugreifen. Dies wird als innerhalb des Blickfelds eines Fachmanns liegend betrachtet.

Ein weiterer Lösungsansatz besteht darin, Vor-Seitenla­ dungs-Merkmale der Speicherverwaltungseinrichtung 134 abzu­ schalten. Der Kern 108 kann beispielsweise die umgebenden Seiten einer Seite, die einen Fehler empfängt, einbringen, in der Voraussicht, daß bald auf diese Seiten zugegriffen wird. Das Vor-Seitenladen ist während normaler Operationen ein exzellentes Merkmal, jedoch nicht während Bewertungsläu­ fen. Dies liegt daran, daß der Zweck des Vor-Seitenladens darin besteht, wirksam Datenstrukturzugriffe zu verbergen, was direkt im Gegensatz zu dem Prozeß der vorliegenden Er­ findung steht. Dies wird als innerhalb des Blickfelds eines Fachmanns liegend betrachtet.

Jedoch werden bei einem weiteren bevorzugten Ausführungsbei­ spiel der vorliegenden Erfindung mehrere Verfahren verwen­ det, um eine Datenprotokollierungseinrichtung 502 zur Folge zu haben, die extrem genaue Ergebnisse ergibt. Der erste Ab­ schnitt dieses bevorzugten Lösungsansatzes besteht darin, einen speziellen Kern zu verwenden, der auf einen speziellen Prozeß abzielt. Statt des Reduzierens des System-RAMs, das alle Prozesse verlangsamt, plaziert ein solcher Kern genau eine Haldenseite in die Speicherverwaltungseinheit 134 der CPU. Dies geschieht durch das Verschlüsseln aller Prozeßsei­ ten in dem RAM, während die Speicherverwaltungseinheit 134 modifiziert wird, um zu glauben, daß eine einzelne Seite in dem RAM ist. Der Zielprozeß wird jedesmal fehlschlagen, wenn er auf eine unterschiedliche Haldenseite zugreift. Es werden nicht nur die meisten Deckdatenstrukturen gefunden, sondern ferner wird die beobachtete Häufigkeit jeder Datenstruktur­ benutzung relativ genau sein. Um das Verhalten zu maximie­ ren, ist der Kern konfiguriert, um die Prozeßhaldenseiten in dem RAM zu halten, und jeden Seitenfehler sehr schnell abzu­ wickeln. Dies wird als in dem Blickfeld eines Fachmanns lie­ gend betrachtet.

Der zweite Abschnitt des bevorzugten Lösungsansatzes, der auch getrennt verwendet werden kann, besteht darin, auf Sei­ tenfehler an spezifischen Datenstrukturen abzuzielen. Bei­ spielsweise kann bei der Unix-Umgebung, bei der das vorlie­ gende Ausführungsbeispiel implementiert ist, die Malloc-Bi­ bliothek modifiziert sein, so daß niemals zwei Datenstruktu­ ren die gleiche Seite gemeinsam benutzen. Diese Modifikation von Malloc wird als Fachleuten gut bekannt betrachtet. Wenn in Verbindung mit dem verbesserten Kern, der oben beschrie­ ben ist, verwendet, wird die Genauigkeit des ADM 100 nahezu perfekt.

3. Protokollieren von Seitenfehlern

Wie oben erläutert wurde, beobachtet das ADM Seitenfehler, wenn ein Prozeß schwerwiegend zeitverschwendend ist. Für je­ den Seitenfehler protokolliert die Datenprotokollierungsein­ richtung 502 Informationen über alle Haldenseitenfehler in einer zeitlich geordneten, zeitlich gestempelten Liste. Be­ zugnehmend auf Fig. 7 werden die folgenden Informationen in einem Schritt 610 protokolliert. Zuerst wird die Adresse, die den Seitenfehler 702 bewirkt, protokolliert. Dies ist die Adresse, auf die zugegriffen wurde, als der Seitenfehler auftrat. Wie anderswo in dieser Anmeldung erläutert ist, protokolliert und analysiert die vorliegende Erfindung Da­ tenstrukturen. Sollte sich die vorliegende Erfindung jedoch auf einen Programmcode richten, dann würde das gezählte Pro­ gramm gespeichert werden. Zusätzlich würde der Programmzäh­ lerwert 704 und der Seitenfehler 702 gespeichert werden. Dies ist die Adresse der Prozedur, die den Seitenfehler be­ wirkt.

Bei dem bevorzugten Ausführungsbeispiel ist der Kern 108 ein HP-UX-Kern. Der HP-UX-Kern liefert die obigen Informationen in einem speziellen Meßinformationspuffer. Zusätzlich exi­ stierte in dem Kern 108 bereits ein Datenprotokollierungs­ werkzeug. Eine Modifikation dieses bereits existierenden Protokollierungsmerkmals des Kerns 108 war notwendig und wurde als im Blickfeld eines Fachmanns liegend betrachtet. Es sollte bemerkt werden, daß dieses Protokollierungswerk­ zeug relativ klein und unauffällig ist.

4. Protokollieren von Haldentransaktionen

Wie oben erläutert wurde, wird im Schritt 610 eine zeitlich geordnete, zeitlich gestempelte Liste von Haldentransaktio­ nen aufgebaut. Wie oben erläutert wurde, ist das bevorzugte Ausführungsbeispiel des Kerns 108 ein Unix-Kern. Im Schritt 610 protokolliert die Datenprotokollierungseinrichtung 502 alle Informationen, die sich auf jeden Aufruf der dynamisch zuordnenden Bibliothek der Programmiersprache C beziehen. Dies schließt Aufrufe von malloc(), calloc(), realloc() und free() ein. Jedoch ist es für Fachleute offensichtlich, daß die vorliegende Erfindung konfiguriert sein kann, um Aufrufe einer beliebigen dynamisch zuordnenden Bibliothek der ge­ wünschten Hochpegelsprache zu protokollieren.

Bezugnehmend auf Fig. 8 schließen die Informationen, die für jede Haldentransaktion protokolliert werden, folgende ein. Die Haldentransaktionsinformationen weisen einen Zugeord­ net/Freigemacht-Status 802 auf. Dieser Status zeigt an, ob der Speicher zugeordnet oder freigemacht war. Die Halden­ transaktionsinformationen weisen ferner die zugeordnete Blockgröße 804 auf. Ferner weisen die protokollierten Hal­ dentransaktionsinformationen die zugeordneten/ freigemachten Adressen 806 auf. Schließlich sind ferner Prozeduraufruf-Zu­ rückverfolgungsdaten 810 protokolliert. Dies schließt die folgenden Informationen für jede Zurückverfolgungslinie ein: der Prozedurname 812 und der Prozedurversatz 814 von dem Be­ ginn der Prozedur, um einen Prozeduraufruf von einem anderen zu unterscheiden; und die Quellendatei 816 der Prozedur.

Die ersten Schwierigkeiten waren: 1) schnell und genau die Prozedurtransaktions-Zurückverfolgung zu bestimmen; und 2) ein Format zu entwickeln, um die Pro-Transaktion-Informatio­ nen schnell und prägnant zu protokollieren. Der erste Ver­ such beim Protokollieren von Informationen für das Hochfah­ ren des X-Servers (d. h. ohne laufende Unterprogramme) benö­ tigte etwa 30 Minuten, um die näherungsweise 17 MByte an In­ formationen zu protokollieren. Der erste Versuch verwendete eine gewöhnliche HP-UX-Zurückverfolgungs-Einrichtung, die vollständige ASCII-Zeichenfolgen für die gesamte Zurückver­ folgung erzeugte, was für den größten Teil der Zeit und des Raums verantwortlich war.

Bei dem bevorzugten Ausführungsbeispiel ist der Prozessor 142 ein PA-RISC-System von Hewlett-Packard und der Kern 108 ist ein HP-UX-Unix-Arbeitssystem. Das Erzeugen einer genauen Zurückverfolgung auf HP-UX ist aufgrund der gemeinsam ver­ wendeten Bibliotheken von PA-RISC schwierig. Folglich ist bei dem bevorzugten Ausführungsbeispiel eine übliche Ein­ richtung verwendet, die ein Array von Adressen zurückgibt. Das Korrelieren dieser Adressen mit Prozedurnamen von der Programmsymboltabelle wurde bis nach der Verarbeitung ver­ zögert (was sich während Bewertungsläufen als effizienter und weniger aufdringlich herausstellte). Das endgültige Pro­ tokollierungsformat war ein sehr knappes binäres Format. Die endgültige Lösung war um zwei Größenordnungen raumeffizien­ ter und um drei Größenordnungen zeiteffizienter als der er­ ste Versuch.

Als nächstes war es wichtig, die gemeinsam benutzte Biblio­ thek libc zu modifizieren, die die Version von malloc() ent­ hält, die die meisten Programme verwenden.

Eine Zeitstempelung der Haldentransaktionsinformationen wird durch das Leiten der Haldendaten zu dem Kern 108 erreicht. Der Kern versieht die Daten mit einem Zeitstempel und verei­ nigt dieselben mit den Seitenfehlerdaten in seinem speziel­ len Meßschnittstellenpuffer, der oben beschrieben wurde. Dies ermöglicht es, daß ein Datenprotokollierungswerkzeug alle Informationen protokolliert.

B. Datenanalysator 504

Der Datenanalysator 504 ist ein interaktives Informations­ verarbeitungswerkzeug, das effizient die großen Datenmengen verarbeitet, die während eines Bewertungslaufs durch die Da­ tenprotokollierungseinrichtung 502 protokolliert werden. Der Datenanalysator 504 ermöglicht ferner, daß Benutzer interak­ tiv die verarbeiteten Daten erforschen, um Einblicke in ei­ nen Prozeßhalden-AWS zu erlangen. Fig. 9 ist ein Flußdia­ gramm der Hauptprozesse, die durch den Datenanalysator 504 durchgeführt werden.

1. Korrelieren von Haldentransaktionen auf C-Datenstrukturtypen

Sobald die oben genannten Informationen für jede Halden­ transaktion durch die Datenprotokollierungseinrichtung 502 protokolliert sind, korreliert der Datenanalysator 504 jeden Block des Haldenspeichers mit einem speziellen C-Datenstruk­ turtyp in einem Schritt 904. Wie detailliert nachfolgend be­ schrieben wird, wird diese Korrelation durch das Vergleichen der protokollierten Informationen gegenüber einem Satz von Regeln erreicht. Der Korrelationsschritt 904 wird nun bezug­ nehmend auf einen beispielhaften Datenstrukturtypen in einem Abtast-X-Server beschrieben. Der Abtast-X-Server ist ein Ab­ tastserver für Workstationbenutzer mit vorrichtungsabhängi­ gen Treibern. Der Abtast-X-Server ist erhältlich von dem X Consortium, Inc., Cambridge, Massachusetts, USA.

Fig. 10 zeigt die Prozeduraufruf-Zurückverfolgungen zum Er­ zeugen einer Fensterstruktur. Bezugnehmend auf Fig. 10 ist einer der wichtigsten Datenstrukturtypen in dem Abtast-X- Server die WindowRec (oder einfach die Window-) Struktur. Obwohl die Größe von Window-Strukturen bei einem Mehr­ schirm-X-Server variieren kann, gibt es nur zwei eindeutige Prozeduraufruf-Zurückverfolgungen, die verwendet werden, um Window-Strukturen zu erzeugen. Bezugnehmend auf Fig. 1 sind dieselben die Prozeduraufruf-Zurückverfolgung 1002 zum Er­ zeugen des Wurzelfensters und die Prozeduraufruf-Zurückver­ folgung 1004 zum Erzeugen von Nebenfenstern. Es sollte be­ merkt werden, daß häufig jeder C-Datenstrukturtyp gerade ei­ ne eindeutige Zuordnungszurückverfolgung aufweist, die ein­ facher ist als die, die in diesem Beispiel dargestellt ist.

Die Prozeduraufruf-Zurückverfolgung 1002 ist in der linken Spalte von Fig. 10 gezeigt. Um das Wurzelfenster zu erzeu­ gen, werden die folgenden Prozeduraufrufe durchgeführt. Der Malloc()-Prozeduraufruf 1006 wurde durch den Xalloc()-Proze­ duraufruf 1008 aufgerufen. Der Xalloc()-Prozeduraufruf 1008 wurde durch den AllocateWindow()-Prozeduraufruf 1010 (Ordne Fenster zu) aufgerufen. Der AllocateWindow()-Prozeduraufruf 1010 wurde durch den CreateRootWindow()-Prozeduraufruf 1012 (Erzeuge Wurzelfenster) aufgerufen. Der CreateRootWindow ()- Prozeduraufruf 1012 wurde durch den Main()-Prozeduraufruf 1014 (Hauptprozeduraufruf) aufgerufen.

Die Prozeduraufruf-Zurückverfolgung 1004 ist in der rechten Spalte von Fig. 10 gezeigt. Um Nebenfenster zu erzeugen wur­ den die folgenden Prozeduraufrufe durchgeführt. Der Malloc()-Prozeduraufruf 1016 wurde durch den Xalloc()-Proze­ duraufruf 1018 aufgerufen. Der Xalloc()-Prozeduraufruf 1018 wurde durch den AllocateWindow()-Prozeduraufruf 1020 aufge­ rufen. Der AllocateWindow()-Prozeduraufruf 1020 wurde durch den CreateWindow()-Prozeduraufruf 1022 aufgerufen. Der CreateWindow()-Prozeduraufruf 1022 wurde durch den Pro- CreateWindow()-Prozeduraufruf 1026 aufgerufen. Der Pro- CreateWindow()-Prozeduraufruf 1026 wurde durch den Main()- Prozeduraufruf 1024 aufgerufen.

Bezugnehmend auf Fig. 10 ist es klar, daß die ersten drei Prozeduren in jeder Zurückverfolgung die gleichen sind. D.h., daß die Prozeduraufrufe 1006, 1008 und 1010 die glei­ chen wie die Prozeduraufrufe 1016, 1018 bzw. 1020 sind. Dies ist nicht unüblich. Tatsächlich sind die ersten zwei und die letzten zwei Prozeduren für die meisten X-Server-Datenstruk­ turtypen häufig identisch. Folglich sind die Prozeduren in der Mitte der Zurückverfolgung im allgemeinen interessanter. Bei diesem Beispiel befindet sich AllocateWindow() in beiden Zurückverfolgungen. Da AllocateWindow() nur einen Aufruf von Xalloc() durchführt, ist jede Haldentransaktion mit Allo­ cateWindow() in der Zurückverfolgung eine Window-Struktur.

Bei der vorliegenden Erfindung weist die bevorzugte Art und Weise, auf die C-Datenstrukturtypen identifiziert werden sollen, eine oder zwei Regeln auf. Regeln sind Spezifikatio­ nen dessen, wie die Zuordnungs- oder Freimachungs-Transak­ tionen der Datenstrukturtypen aussehen. Regeln sind in der Technik gut bekannt und sind analog zu "Regelausdrücken". Einem Satz von Regeln ist ein Name gegeben (typischerweise der Strukturtypname). Diese Regeln werden mit jeder Halden­ transaktion verglichen. Es existieren Auswahlkriterien, die der Datenanalysator 504 verwendet, um zu bestimmen, welche Transaktionen welchen C-Datenstrukturtypen entsprechen. Wenn eine Regel mit einer Transaktion übereinstimmt, wird der entsprechende Haldenblock identifiziert. Der Datenanalysator 504 implementiert diesen Lösungsansatz in einer interaktiven Form durch den Regelspeicher 506 und den Regeleditor 508.

Die Regeln, die bei dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung verwendet werden, ermöglichen es, daß jede Datenstruktur mehr als einmal identifiziert wird. Manchmal ist es nützlich, eine Hierarchie der Datenstruktur­ typnamen zu besitzen. Beispielsweise werden Pixeltabellen (pixmaps) für eine Vielzahl von Zwecken in dem Abtast-X-Ser­ ver verwendet (beispielsweise für eine Externspeicherung, Ziegel (tiles), Punktierungen (stipples)). Daher kann ein Regelsatz alle Pixeltabellen identifizieren, während ein weiterer Regelsatz spezielle Typen von Pixeltabellen identi­ fizieren kann.

Für Programme mit großen Anzahlen von Strukturtypen kann die Regelerzeugung zeitverbrauchend sein. Um die Regelerzeugung zu erleichtern, verwendet der Datenanalysator 504 eine Re­ gelverwaltungseinrichtung 506, die es ermöglicht, daß Benut­ zer Regelsätze interaktiv verwalten. Außerdem weist der Re­ geleditor 508 ein Dialogprogramm auf, das es ermöglicht, daß ein Benutzer interaktiv Regeln erzeugt und editiert. Weitere gut bekannte Merkmale werden in der Regelverwaltungseinrich­ tung 506 und dem Regeleditor 508 verwendet, um die Regel-Er­ zeugung und -Verwaltung zu erleichtern. Beispielsweise kann jeder Abschnitt einer Regel durch Stellvertreterzeichen er­ setzt sein (wild-carded). Dies erhöht die Leistung jeder Re­ gel, was die Erzeugungszeit der Regel verringert. Außerdem können Regeldateien gelesen und geschrieben werden, um Re­ geln zwischen Datenanalysesitzungen zu bewahren. Halden­ transaktionen können auf eine Anzahl von Arten in dem Regel­ editor 508 betrachtet werden. Beispielsweise können Benutzer den Regeleditor mit Anfangswerten starten, die auf diejeni­ gen der betrachteten Transaktion eingestellt sind.

Die Stellvertreterzeichen-Merkmale, die oben erwähnt wurden, werden nachfolgend detaillierter beschrieben. Unter Verwen­ dung des Fensterstrukturbeispiels, das in Fig. 10 gezeigt ist, enthielt die Zurückverfolgung für jede Zuordnungstrans­ aktion die Prozedur AllocateWindow(). Ferner führte die Pro­ zedur AllocateWindow() 1010, 1020 nur einen Aufruf von Xalloc() 1008, 1018 durch, um ein Fenster zu erzeugen. Folg­ lich ist eine offensichtliche Regel, die die Fensterstruktu­ ren identifiziert, jede Transaktion, für die die Zurückver­ folgung das Wort AllocateWindow enthält. Es sei bemerkt, daß kein anderer Teil einer Transaktion in dieser Regel spezifi­ ziert ist - alle Werte werden als mit durch Stellvertreter­ zeichen ersetzte Abschnitte einer Regel übereinstimmend be­ trachtet.

Wenn eine bestimmte nicht identifizierte Struktur viele Sei­ tenfehler bewirkt, rollt bei dem bevorzugten Ausführungsbei­ spiel eine Menüauswahl das Regeleditor-Dialogprogramm nach oben auf, wobei Anfangswerte auf die der Strukturzuordnungs­ transaktion eingestellt sind. Die anfänglichen Regelwerte können editiert werden (um dieselben beispielsweise allge­ meiner zu machen) und mit einem Namen versehen werden (typi­ scherweise dem tatsächlichen C-Datenstrukturtypnamen). Wenn die Regel gesichert ist, wird dieselbe mit allen Transaktio­ nen verglichen, um alle übereinstimmenden Speicherblöcke zu identifizieren. Der Benutzer kann nun Informationen für jede Datenstruktur dieses Typs untersuchen.

2. Informationsverarbeitung

Nachdem die Bewertung abgeschlossen ist und die oben genann­ ten Informationen protokolliert und korreliert sind, wird ein Informationsverarbeitungsschritt durchgeführt, bei dem eine näherungsweise Bestimmung des AWS der Zielprozeßhalde durchgeführt wird. Dieser Abschnitt beschreibt den allgemei­ nen Algorithmus zum Verarbeiten der protokollierten und kor­ relierten Informationen.

Zuerst werden die Transaktionsdaten in einem Schritt 906 verarbeitet, um dieselben in eine Form zu plazieren, die für eine Datenanalyse geeignet ist. Die Transaktionsverarbeitung im Schritt 906 wird detaillierter nachfolgend bezugnehmend auf Fig. 11 beschrieben.

Als nächstes wird eine Reihe von Funktionen, die allgemein als Seitenfehlerverarbeitung bezeichnet werden, im Schritt 908 durchgeführt. Im Schritt 908 werden die Seitenfehlerda­ ten eingelesen und mit den Haldentransaktionsdaten korre­ liert. Verbindungen zwischen entsprechenden Datenstrukturen und Seitenfehlern werden eingestellt. Dies ist detailliert nachfolgend bezugnehmend auf Fig. 12 beschrieben.

a. Transaktionsverarbeitung - Schritt 906

Die Verarbeitung, die auf den Haldentransaktionsdaten durch­ geführt wird, wird nun bezugnehmend auf Fig. 11 beschrieben. Zuerst wird in einem Schritt 1104 die Zielprozeß-Symbolta­ belle in eine bequeme Datenstruktur gelesen (beispielsweise eine Hash-Tabelle). Dann können die Haldentransaktionsdaten gelesen und verarbeitet werden.

Als nächstes wird in einem Schritt 1106 jede Haldentransak­ tion als eine Zuordnungs- oder Freimachungs-Transaktion identifiziert. Die zugeordnete Adresse jeder Zuordnungs­ transaktion wird mit einer Hash-Codierung versehen. Dies vereinfacht die Software, die dem Schritt 908 zugeordnet ist, welcher Zuordnungs- und Freimachungs-Transaktionen vergleicht. Wenn ein übereinstimmender Satz von Transaktio­ nen gefunden ist, werden dieselben kreuzverbunden.

In einem Schritt 1108 wird jede Linie einer Zurückverfolgung in einen Prozedurnamen, einen Dateinamen und einen Versatz in der Prozedur umgewandelt. Der Prozedurname ist erforder­ lich, da jede Linie einer Zurückverfolgung einfach als eine Adresse protokolliert ist. Der Versatz ist die Anzahl von Bytes von dem Beginn der Prozedur. Da jede Linie einer Zu­ rückverfolgung mehrere Male gesehen werden kann, wird jede Linie in eine Hash-Tabelle gegeben. Diese Hash-Tabelle er­ zeugt einen eindeutigen 32-Bit-Schlüsselwert für jede ein­ deutige Zurückverfolgungslinie. Dies reduziert die Datenmen­ ge, die der Datenanalysator 504 speichert, ebenso wie die Zeit, die für die Durchführung der weiteren Verarbeitung (Schritt 1206) benötigt wird.

Im Schritt 1108 wird jede Zurückverfolgung als ein Array von Zurückverfolgungslinien-Schlüsseln gespeichert. Wie bei den Zurückverfolgungslinien wird auch jede Zurückverfolgung in eine Hash-Tabelle gegeben, und ein eindeutiger Schlüsselwert wird für jede eindeutige Zurückverfolgung erzeugt. Jede Transaktion speichert den eindeutigen Schlüssel für ihre Zu­ rückverfolgung.

b. Seitenfehlerverarbeitung - Schritt 908

Wie oben bezugnehmend auf Fig. 9 erläutert wurde, kann, nachdem die Transaktionsdaten verarbeitet und in eine Form, die für eine Datenanalyse geeignet ist, plaziert sind, eine Seitenfehlerverarbeitung im Schritt 908 stattfinden. Fig. 12 ist ein Flußdiagramm der Schritte, die während des Seiten­ fehler-Verarbeitungsschritts 908 durchgeführt werden. Bezug­ nehmend auf Fig. 12 wird nachfolgend die bevorzugte Seiten­ fehlerverarbeitung beschrieben.

Im Schritt 1204 wird jede Freimachungs-Transaktion mit ihrer entsprechenden Zuordnungs-Transaktion verglichen. Dies iden­ tifiziert die Zeitperiode, zu der der Haldenblock zugeordnet wurde. Wenn keine Freimachungs-Transaktion protokolliert wurde, die mit einer Zuordnungs-Transaktion übereinstimmt, ist der entsprechende Speicherblock ein potentielles Spei­ cherleck.

Als nächstes wird jeder Seitenfehler mit der C-Datenstruktur korreliert, die denselben bewirkt hat. Zuerst werden in ei­ nem Schritt 1206 die Datenstrukturtypen unter Verwendung von Regeln mit dem zugehörigen Haldenspeicherblock verglichen. Dann wird in einem Schritt 1208 die Adresse des Seitenfeh­ lers mit allen entsprechenden Speicherblöcken über der Zeit verglichen. Wenn mehr als eine Übereinstimmung existiert, wird in einem Schritt 1210 ein Zeitstempelvergleich durchge­ führt, um zu bestimmen, welche Datenstruktur den Seitenfeh­ ler bewirkte. Folglich wird die Adresse, die jeden Fehler bewirkte, mit den Haldeninformationen verglichen, bis die­ selbe mit einer speziellen Datenstruktur übereinstimmt. Der Seitenfehlerprozeß endet an einem Block 1212.

Es sei beispielsweise angenommen, daß ein spezieller Fehler nach 13 Minuten in einem Bewertungslauf auftritt. Die Adres­ se, die den Fehler bewirkt (0x400ab340), fällt in den Adreß­ bereich von drei unterschiedlichen Paaren von Haldentransak­ tionen. Nach dem Vergleichen der Zeitstempel wird offen­ sichtlich, welches Paar dem Seitenfehler entspricht.

Alle diese neu vernetzten Informationen können nun analy­ siert werden, um Einblicke über den AWS zu erlangen.

c. Benutzeranalyse

Sobald der Seitenfehlerverarbeitungsschritt 908 abgeschlos­ sen ist, können die Daten auf viele unterschiedliche Arten analysiert werden. Die Daten können mit Datenanalyse-Anzei­ gehistogrammen sortiert werden (beispielsweise durch die An­ zahl der Seitenfehler, durch die Strukturgrößen). Jede Hi­ stogrammlinie kann ausgewählt werden, und zusätzliche Infor­ mationen können angefordert werden. "Speichertabellen"-Gra­ phen können angezeigt werden, die grafisch die Größe und die Plazierung der gewählten Datenstrukturen zeigen, um die Lo­ kalität zu zeigen.

d. Regelvergleich

Regeln werden mit Transaktionen verglichen, wann immer die­ selben erzeugt oder aus einer Regeldatei gelesen werden. Die Struktur der Transaktionsdatenbank macht das Regelverglei­ chen einfach.

Zuerst wird jede Linie einer Regel mit jeder Zurückverfol­ gungslinie in der Transaktionsdatenbank verglichen. Wenn Übereinstimmungen gefunden werden, wird (werden) der (die) eindeutige(n) Schlüssel aufgezeichnet (bemerke: aufgrund von Stellvertreterzeichen (wild-cards) kann eine Regellinie mit mehr als einer Zurückverfolgungslinie übereinstimmen). Wenn irgendwelche Regellinien keine Übereinstimmung finden, wird die gesamte Regel mit keinen Transaktionen übereinstimmen, und die Verarbeitung endet für diese Regel.

Nachdem die Regellinien verglichen wurden, wird die Zurück­ verfolgungsregel mit jeder eindeutigen Zurückverfolgung von der Transaktionsdatenbank verglichen. Für jede übereinstim­ mende Zurückverfolgung wird der eindeutige Schlüssel aufge­ zeichnet. Dann werden die Transaktionen selbst mit der voll­ ständigen Regel verglichen (das Vergleichen der Zurückver­ folgungen ist ein einfacher Integer-Vergleich der 32-Bit- Schlüssel). Vernetzungen werden zwischen Regeln und überein­ stimmenden Transaktionen eingestellt, welche das interaktive Verhalten der Datenanalyse verbessern.

Wie oben beschrieben wurde, werden bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung die Daten­ strukturen eines Prozesses protokolliert und analysiert. Es sollte jedoch für Fachleute offensichtlich sein, daß die AWS-Bestimmungseinrichtung 500 der vorliegenden Erfindung konfiguriert sein kann, um andere Charakteristika eines Pro­ zesses, beispielsweise den Prozeßcode und globale Variablen, zu protokollieren und analysieren.

Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung führt der Datenanalysator 504 seine Funktionen durch, nachdem der Bewertungslauf abgeschlossen ist und die Datenprotokollierungseinrichtung die notwendigen Informatio­ nen gespeichert hat. Es sollte jedoch für Fachleute offen­ sichtlich sein, daß sich der Datenanalysator 504 in einem anderen Prozessor befinden kann und in Echtzeit mit der Da­ tenprotokollierungseinrichtung 502 arbeitet. Beispielsweise bei einem Ausführungsbeispiel, bei dem das Computersystem 100 mit einem Netzwerk verbunden ist, können die Daten, die durch die Datenprotokollierungseinrichtung 502 protokolliert werden, in Speichervorrichtungen gespeichert werden, die über das Netzwerk mit dem Computersystem 100 in Kommunika­ tion stehen. Wenn das Computersystem 100 mit einem Netzwerk verbunden ist, kann sich der Datenanalysator 504 ferner in einem getrennten Computersystem befinden, das Datenanalyse­ funktionen durchführt, nachdem der Bewertungslauf abge­ schlossen ist.

In der vorherigen Beschreibung wurde die vorliegende Erfin­ dung bezugnehmend auf die Sprache C und die HP-UX-Unix-Umge­ bung beschrieben. Für Fachleute ist jedoch offensichtlich, daß die vorliegende Erfindung mit einer beliebigen Hochpe­ gel-Programmiersprache, beispielsweise Fortran, arbeiten kann. Außerdem kann die vorliegende Erfindung in einem be­ liebigen Betriebssystem arbeiten, wie z. B. Windows/NT, VMS, Open VMS, T/20, usw . . Die Bestimmungseinrichtung 500 des tatsächlichen Arbeitssatzes, einschließlich der Datenproto­ kollierungseinrichtung 502 und des Datenanalysators 504, stellt vorzugsweise Computer-Programme und/oder -Bibliothe­ ken dar, die sich (während der Ablaufzeit) in dem Hauptspei­ cher 136 befinden, und die durch die Prozessoren in dem Com­ putersystem 100, beispielsweise den Prozessor 142, ausge­ führt werden. Die Daten, die durch die Datenprotokollie­ rungseinrichtung 502 protokolliert werden, können in dem se­ kundären Speicher 138 gespeichert werden. Ferner können die Computer-Programme/Bibliotheken, die der AWS-Bestimmungsein­ richtung 500 zugeordnet sind, auf einer Diskette oder einem anderen austauschbaren Speichermedium gespeichert sein.

Es sollte offensichtlich sein, daß die Ausführungsbeispiele der vorliegenden Erfindung hardwaremäßig, softwaremäßig oder als eine Kombination derselben implementiert sein können. Bei derartigen Ausführungsbeispielen würden die verschiede­ nen Komponenten und Schritte hardwaremäßig und/oder soft­ waremäßig implementiert werden, um die Funktionen der vor­ liegenden Erfindung durchzuführen. Jede gegenwärtig erhält­ liche oder zukünftig entwickelte Computersoftwaresprache und/oder alle Hardwarekomponenten können bei Ausführungsbei­ spielen der vorliegenden Erfindung verwendet werden.

VI. Fallstudie: Speicherabstimmung des HP-X-Servers unter Verwendung der AWS-Bestimmungseinrichtung

Eine Beschreibung der Implementierung der AWS-Bestimmungs­ einrichtung 500, um eine Speicherabstimmung des X-Servers von Hewlett-Packard durchzuführen, folgt nun.

Der Abtast-X-Server, der in dieser Fallstudie verwendet ist, ist der Abtast-X-Server, 5th Release, erhältlich von X Con­ sortium, Cambridge, Massachusetts. Das Personal des Consor­ tiums hat eine bekannte Speicherabstimmung ohne die Verwen­ dung der vorliegenden Erfindung durchgeführt. Trotz dieser Arbeit gab es noch Raum für eine Verbesserung.

A. Fenster

Drei Verbesserungstypen wurden für Strukturen, die sich auf Fenster beziehen, durchgeführt. Erstens wurde die Lokalität des Fensterbaums mit der Verwendung einer Universalbiblio­ thek, die mit ChunkAlloc bezeichnet wird, verbessert. Zwei­ tens wurde die Größe der privaten Fensterstrukturen redu­ ziert. Schließlich wurde die Lokalität der WindowOptRec-Da­ tenstrukturen unter Verwendung von ChunkAlloc ebenfalls ver­ bessert.

1. Fensterlokalität

Wie in früheren Abschnitten dargestellt wurde, wird jede Fensterstruktur einzeln zugeordnet. Fenster sind gemäß ihrer hierarchischen Beziehungen (d. h. dem Baum) miteinander ver­ bunden. Der Fensterbaum wird relativ häufig durchlaufen. Die Intuition legt nahe, daß Fensterstrukturen eine schlechte Lokalität zueinander haben werden, was den VWS des X-Servers vergrößern wird und unnötige Seitenfehler bewirken wird. Die AWS-Bestimmungseinrichtung 500 bestärkte diese Intuition. ADM-Bewertungsläufe zeigten, daß auf Fensterstrukturen häu­ fig zugegriffen (d. h. in dem AWS) wird und dieselben eine schlechte Lokalität aufweisen (d. h. den VWS vergrößern). Der X-Server wurde geladen, um Fenster in Gruppen (die Blöcke (chunks) genannt werden) unter Verwendung einer Bibliothek, die ChunkAlloc genannt wird, zuzuordnen.

B. Größenreduzierung

Zusätzlich zu der neu verbesserten Lokalität zeigte die AWS-Bestimmungseinrichtung 500, daß Fensterstrukturen sehr groß waren. Dies bedeutete, daß relativ wenig Fenster auf jede Seite passen. Folglich würde jede Fensterbaumüberque­ rung noch auf eine große Anzahl von Seiten zugreifen.

Hewlett-Packard hat in neuerer Zeit große Verbesserungen des Verhaltens seines X-Servers erreicht. Eine gänzlich neue Ge­ neration eines DDX-Codes wurde entwickelt. Ungünstigerweise verwendete der neue DDX-Code noch private Strukturen einer vorherigen Generation. Nur einige wenige Felder von diesen alten privaten wurden verwendet, wobei ein beträchtlicher Speicher, der für jedes Fenster verschwendet wurde, belassen wird.

Nach einer Umstrukturierung der privaten Struktur verwendete der neuere DDX-Code näherungsweise 200 Bytes pro Fenster we­ niger. Bei einer Kombination mit ChunkAlloc waren die Fen­ ster nun lokal und klein, was viel weniger Seitenfehler zur Folge hatte.

C. WindowOpt-Lokalität

Das Kernprotokoll XII spezifiziert eine Anzahl von Attribu­ ten für jedes Fenster. Während des R4-Versuchs bemerkte das Personal des Consortiums, daß die meisten Fenster mehrere der Attribute nicht verwenden. Dies führte sie dazu, die Fensterstruktur zu teilen. Sie erzeugten eine neue Window Opt-Struktur, die zugeordnet ist, wenn ein Fenster die we­ nig-verwendeten Attribute verwendet.

Die Analyse der AWS-Bestimmungseinrichtung 500 zeigte, daß ein beträchtlicher Prozentsatz der Fenster (zumindest für die spezielle Bewertung) WindowOpt-Strukturen verwendete. Die AWS-Bestimmungseinrichtung 500 zeigte ferner Lokalitäts­ probleme, ähnlich denen, die mit der Hauptfensterstruktur zu sehen sind. Daher wurde eine ChunkAlloc-Bibliothek verwen­ det, um die Lokalität zu verbessern.

D. Betriebsmittellokalität

Bei der Nebenstellen-Server-Natur des X11 nehmen Nebenstel­ len keinen direkten Bezug auf Server-interne Datenstruktu­ ren. Statt dessen verwenden Nebenstellen Betriebsmitteliden­ tifizierer, um auf diesen Strukturen (Betriebsmitteln) zu arbeiten. Der Server hält eine Betriebsmitteldatenbank, die eine Abbildung zwischen Betriebsmittelidentifizierern und Server- internen Datenstrukturen enthält.

Jedem Betriebsmittel in der Datenbank ist eine kleine 16- Byte-Datenstruktur zugeordnet. Die AWS-Bestimmungseinrich­ tung 500 zeigte, daß diese kleinen Strukturen häufig verar­ beitet wurden und viele Seitenfehler bewirkten. Das Betrach­ ten der Speichertabelle dieser Strukturen zeigte ein defini­ tes Lokalitätsproblem. Wiederum wurde ChunkAlloc verwendet. Die Lokalität wurde verbessert und Seitenfehler wurden redu­ ziert.

E. Fonts

Unter Verwendung der Erfindung wurde gezeigt, daß der Code, der Bittabellen-Fonts öffnet, sehr verschwenderisch war. Je­ desmal, wenn ein Bittabellen-Font geöffnet wurde, wurden ei­ ne große Struktur (näherungsweise 80 KByte) und viele kleine Strukturen zugeordnet, verwendet und dann freigemacht. Auf­ grund anderer Operationen, die zwischen der Zeit, zu der je­ de Bittabelle geöffnet wurde, auftreten, fragmentierten die­ se vorübergehenden Strukturen die Halde, wobei die Lokalität anderer AWS-Strukturen verschlechtert wurde.

Die Untersuchung dessen, was der Bittabellen-Fontcode ver­ suchte zu tun, zeigte, daß die große Datenstruktur zufällig groß war - sie mußte nur wenige KByte groß sein, nicht 80.

Eine kleine Gebrauchsbibliothek wurde erzeugt, die ermög­ lichte, daß kleinere vorübergehende Strukturen von größeren weniger vorübergehenden Blöcken des Speichers zugeordnet wurden. Dies reduzierte die Fragmentierung weiter. Die Ver­ wendung dieser gleichen Bibliothek für nichtvorübergehende Font-Strukturen verbesserte die Lokalität weiter.

Claims (18)

1. System (500) zum Bestimmen des tatsächlichen Arbeits­ satzes (406) eines Prozesses in einem Computersystem (100) mit virtuellem Speicher mit folgenden Merkmalen:
einer Datenprotokollierungseinrichtung (502), die kon­ figuriert ist, um konsistente Bewertungen auszuführen, während derer die Datenprotokollierungseinrichtung (502) dynamisch zugeordnete Transaktionen und Seiten­ fehlerinformationen des virtuellen Speichers protokol­ liert; und
einem Datenanalysator (504), der mit der Datenprotokol­ lierungseinrichtung (502) gekoppelt ist und konfigu­ riert ist, um jeden Block eines dynamisch zugeordneten Speichers mit einer speziellen Hochpegelsprachen-Daten­ struktur zu korrelieren.

2. System (500) gemäß Anspruch 1, bei dem:
die Datenprotokollierungseinrichtung (502) eine Ein­ richtung zum Kompilieren einer zeitlich geordneten, zeitlich gestempelten Seitenfehlerliste und einer zeit­ lich geordneten, zeitlich gestempelten Seitentransak­ tionsliste aufweist; und
der Datenanalysator (504) eine Einrichtung zum Korre­ lieren der Seitenfehlerliste und der Seitentransak­ tionsliste aufweist, wobei Seitentransaktionen durch Vergleichen der Seitentransaktionen mit einem Satz von Regeln Datenstrukturtypen zugeordnet werden, wobei jede der Regeln eine Sequenz von Zuordnungs- und Freima­ chungs-Transaktionen für einen der Datenstrukturtypen definiert, und der ferner folgende Merkmale aufweist:
eine Transaktionsverarbeitungseinrichtung zum Iden­ tifizieren von Zuordnungstransaktionen und Freima­ chungstransaktionen, und
eine Fehlerverarbeitungseinrichtung zum Korrelieren der Seitenfehlerliste und der Seitentransaktionsliste und zum Bilden von Verbindungen zwischen Seiten­ fehlern und zugeordneten Hochpegel-Datenstrukturen.

3. System (500) gemäß Anspruch 2, bei dem die Fehlerver­ arbeitungseinrichtung eine Einrichtung zum Korrelieren von Codeprozeduren, die jeden der Fehler bewirkten, mit den Hochpegel-Datenstrukturen aufweist.

4. System (500) gemäß einem der Ansprüche 1 bis 3, bei dem das Computersystem mit virtuellem Speicher einen Be­ triebssystemkern (108) und einen physikalischen Spei­ cher (136) aufweist, wobei der Betriebssystemkern (108) nur eine virtuelle Seite (210) des Prozesses in dem physikalischen Speicher (136) hält, wodurch jedesmal ein Fehler bewirkt wird, wenn versucht wird, auf eine andere virtuelle Seite (210) als die eine virtuelle Seite (210) zuzugreifen.

5. System (500) gemäß einem der Ansprüche 1 bis 4, bei dem der Datenanalysator (504) eine Regelverwaltungseinrich­ tung (506) zum interaktiven Verwalten des Satzes von Regeln und einen Regeleditor (508) zum interaktiven Er­ zeugen und editieren von Regeln aufweist.

6. Verfahren zum Bestimmen des tatsächlichen Arbeitssatzes (406) eines Prozesses mit dynamisch zugeordneten Daten­ strukturen in einem virtuellen Speichersystem (100) zur verbesserten Speicherabstimmung mit folgenden Schrit­ ten:
Einführen (606) einer im wesentlichen hohen Seitenfeh­ lerrate für den Prozeß;
Ausführen (608) einer im wesentlichen wiederholbaren Bewertung auf dem Prozeß;
Protokollieren (610, 612) von Prozeßinformationen, ein­ schließlich des Kompilierens einer zeitlich geordneten, zeitlich gestempelten Seitenfehlerliste und einer zeit­ lich geordneten, zeitlich gestempelten Seitentransak­ tionsliste; und
Analysieren (902) der Prozeßinformationsdaten, um Blöcke eines Haldenspeichers mit den Datenstrukturen zu korrelieren, mit folgenden Schritten:
Korrelieren (904) der Prozeßinformationen, wobei Sei­ tentransaktionen Datenstrukturtypen zugeordnet wer­ den, durch Vergleichen der Transaktionen mit einem Satz von Regeln, wobei jede der Regeln eine Sequenz von Zuordnungs- und Freimachungs-Transaktionen für einen der Datenstrukturtypen definiert, und
Verarbeiten des Prozesses und der korrelierten Infor­ mationen, um den tatsächlichen Arbeitssatz (406) des Prozesses zu bestimmen, mit:
einer Transaktionsverarbeitung (906), welche das Identifizieren von Zuordnungstransaktionen und Freimachungstransaktionen einschließt, und
einer Fehlerverarbeitung (908), welche das Korre­ lieren der Seitenfehlerliste und der Seitentransak­ tionsliste und das Bilden von Verbindungen zwischen den Blöcken eines Haldenspeichers und der Daten­ strukturen einschließt.

7. Verfahren gemäß Anspruch 6, bei dem das virtuelle Spei­ chersystem (100) eine Mehrzahl virtueller Speichersei­ ten (210) aufweist, und bei dem der Einführungsschritt (606) erreicht wird, indem nur eine der Datenstrukturen auf jeder der virtuellen Seiten (210) vorliegt.

8. Verfahren gemäß Anspruch 6 oder 7, bei dem das virtuel­ le Speichersystem (100) einen Betriebssystemkern (108) und einen physikalischen Speicher (136) aufweist, und bei dem der Einführungsschritt (606) durch den Be­ triebssystemkern (108) erreicht wird, indem nur eine virtuelle Seite (210) des Prozesses in dem physikali­ schen Speicher (136) gehalten wird, wodurch jedesmal ein Fehler bewirkt wird, wenn versucht wird, auf eine andere virtuelle Seite (210) als die eine virtuelle Seite (210) zuzugreifen.

9. Verfahren gemäß einem der Ansprüche 6 bis 8, bei dem die Seitentransaktionsliste Speicherstatusdaten (802), die anzeigen, ob ein Speicherblock zugeordnet oder ob der Block freigemacht ist, Blockgrößendaten (804), Blockadreßdaten (806), einen Zeitstempel (807) und Pro­ zeduraufruf-Zurückverfolgungsdaten (810), welche einen Prozedurnamen (812), einen Prozedurversatz (814) und einen Prozedurquellendateinamen (816) einschließen, aufweist.

10. Verfahren gemäß einem der Ansprüche 6 bis 9, bei dem der Fehlerverarbeitungsschritt (908) das Korrelieren von Codeprozeduren, die jeden der Fehler bewirkten, mit den Datenstrukturen aufweist.

11. Verfahren gemäß einem der Ansprüche 6 bis 10, bei dem die Seitenfehlerliste eine Seitenfehleradresse (702) und einen Seitenfehler-Zeitstempel (706) aufweist.

12. Verfahren gemäß einem der Ansprüche 6 bis 11, bei dem die Prozeßinformationen Daten aufweisen, die sich auf globale Variablen des Prozesses beziehen, und bei dem der Fehlerverarbeitungsschritt (908) das Korrelieren von Zugriffen auf die globalen Variablen mit den Sei­ tenfehlern aufweist.

13. Verfahren gemäß einem der Ansprüche 6 bis 12, bei dem die Prozeßinformationen Daten aufweisen, die sich auf Programmcode-Prozeduren des Prozesses beziehen, und bei dem der Fehlerverarbeitungsschritt (908) das Korrelie­ ren von Aufrufen dieser Prozeduren mit den Fehlern auf­ weist.

14. Verfahren gemäß einem der Ansprüche 6 bis 13, bei dem die Prozeßinformationen Daten aufweisen, die sich auf statisch zugeordnete Objekte des Prozesses beziehen, und bei dem der Fehlerverarbeitungsschritt (908) das Korrelieren von Zugriffen auf die Objekte mit den Sei­ tenfehlern aufweist.

15. Verfahren gemäß einem der Ansprüche 6 bis 14, bei dem der Transaktionsverarbeitungsschritt (906) das Lesen (1104) einer Symboltabelle des Prozesses in eine Hash- Tabelle aufweist.

16. Verfahren gemäß einem der Ansprüche 6 bis 15, das fer­ ner den Schritt des Anzeigens der verbundenen Daten des Fehlerverarbeitungsschrittes (908) aufweist.

17. Verfahren gemäß einem der Ansprüche 6 bis 16, bei dem der Fehlerverarbeitungsschritt (908) das Vergleichen jeder der Zuordnungstransaktionen mit einer der Freima­ chungstransaktionen und das Korrelieren von jedem der Seitenfehler mit einer der Datenstrukturen aufweist.

18. Verfahren gemäß einem der Ansprüche 6 bis 17, bei dem der Fehlerverarbeitungsschritt (908) das Anzeigen eines möglichen Speicherlecks aufweist, wenn eine der Freima­ chungstransaktionen nicht mit einer der Zuordnungs­ transaktionen übereinstimmt.