DE112012000635T5

DE112012000635T5 - Dynamische Speicherverwaltung in einer virtualisierten Datenverarbeitungsumgebung

Info

Publication number: DE112012000635T5
Application number: DE112012000635T
Authority: DE
Inventors: Abel Gordon; Michael Hines; Dilma Menezes da Silva; Shmuel Ben Yehuda
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-03-13
Filing date: 2012-03-09
Publication date: 2013-11-14
Also published as: US8943260B2; US20120233435A1; CN103430159A; GB2502751B; WO2012123871A1; GB2502751A; GB201316645D0; CN103430159B

Abstract

Es wird ein Speicherverwaltungsverfahren in einer virtualisierten Datenverarbeitungsumgebung bereitgestellt, bei dem ein Hypervisor mindestens eine virtuelle Maschine (VM) auf einer Hostmaschine realisiert, wobei ein Gastbetriebssystem (BS) auf der VM ausgeführt wird und eine Anwendung, die Speicherverwaltungsfähigkeiten unterstützt, auf dem Gast-BS ausgeführt wird. Das Verfahren weist das Aufrufen eines ersten, von der Anwendung realisierten Speichermanagers (Java-Balloon) auf, zwecks Aufhebens der Zuordnung von der Anwendung zugeordnetem Speicher zur Verwendung durch den Hypervisor, als Reaktion auf eine von dem Hypervisor gesendete Anforderung, und das Aufrufen eines zweiten, auf dem Gast-BS realisierten Speichermanagers (Gast-Balloon) zwecks Aufhebens der Zuordnung von dem Gast-BS zugeordnetem Speicher, als Reaktion auf eine von dem Hypervisor gesendete Anforderung.

Description

TECHNISCHES GEBIET
Der offenbarte Gegenstand betrifft allgemein dynamische Speicherzuordnung und insbesondere ein System und Verfahren zum Steuern der Größe zugeordneten Speichers, der zu einem Programm gehört, das in einer virtualisierten Datenverarbeitungsumgebung ausgeführt wird.
HINTERGRUND
Dynamische Speicherzuordnung bezieht sich auf die Zuordnung von Speicher zu einem Computerprogramm während der Laufzeit dieses Programms. Die dynamische Zuordnung trägt zum effizienten Verteilen begrenzter Speicherressourcen auf mehrere Programme bei, die zur selben Zeit ausgeführt werden. Der Speicher kann den Programmen aus einem Pool ungenutzten Speichers zugeordnet werden, der von einer als Freispeicher (heap) bezeichneten Datenstruktur oder einer anderen geeigneten Speicherverwaltungs-Datenstruktur verwaltet wird. Wenn ein Programm den Speicher nicht länger benötigt, wird der zugeordnete Speicher freigegeben (d. h., die Zuordnung wird aufgehoben) und an den Freispeicher zurückgegeben.
Dynamische Speicherzuordnung in einer virtualisierten Umgebung stellt im Allgemeinen höhere Anforderungen dar, da die Speicherressourcen unter mehreren virtualisierten Komponenten aufgeteilt werden, wie beispielsweise einem Hypervisor, einer oder mehreren virtuellen Maschinen (VMs) und der entsprechenden Gastsoftware. Ein Hypervisor läuft auf einer Hostmaschine, um das Zuordnen von Ressourcen zu den VMs zu unterstützen. Eine VM ermöglicht das Ausführen von Gastsoftware auf der Hostmaschine, ohne dass die Gastsoftware Kenntnis von der zugrunde liegenden Hardwarespezifikation der Hostmaschine hat. Mit anderen Worten: Eine VM stellt eine plattformunabhängige (d. h. eine virtuelle) Ausführungsumgebung für die Gastsoftware bereit.
In einer virtualisierten Umgebung ist der Speicherplatz für die Gastsoftware in Blöcke von üblicherweise 4 KB aufgeteilt, die als Seiten bezeichnet werden. Der physische Speicher (d. h. der Speicher der Hostmaschine) ist auch in Blöcke von üblicherweise ebenfalls 4 KB unterteilt. Wenn der Speicher des Hosts voll ist, werden die Daten virtueller Seiten, die nicht im Speicher des Hosts vorliegen, auf der Festplatte gespeichert. Daher können drei Speicherschichten vorhanden sein: virtueller Speicher des Gasts, physischer Speicher des Gasts und physischer Speicher des Hosts. Wenn der Speicher dynamisch zugeordnet wird, nutzt jeder Gast Speicher auf der Grundlage seiner konfigurierten Größe plus zusätzlichem Überhangspeicher für Virtualisierung.
Manchmal nutzen die Gäste mehr Speicher, als dem Host physisch zur Verfügung steht. Beispielsweise können drei Gäste, denen jeweils 2 GB Speicher zugeordnet wurden, auf einem Host mit 4 GB physischem Speicher laufen. In diesem Fall heißt es, dass der Speicher mit etwa 2 GB überbelegt ist. Zur Verbesserung der Speichernutzung kann der Hypervisor die Zuordnung von Speicher zu im Leerlauf befindlicher Gastsoftware aufheben und den Speicher Gastsoftware zuordnen, die mehr Speicher benötigt.
Wenn die Gesamtmenge des Speichers in dem Host gering ist, gibt möglicherweise keine Gastsoftware physischen Speicher des Gasts frei, da das Gast-BS den Speichermangel des Hosts nicht erkennen kann. Insbesondere bei Java Virtual Machines (JVMs), die plattformunabhängige Ausführungsumgebungen zum Umwandeln und Ausführen von Java-Bytecode sind, fehlt ein automatischer Mechanismus zum externen Steuern der Größe des Freispeichers während der Laufzeit. Bei einer JVM sind beim Start der JVM die Minimal- und die Maximalwerte für die Größe des Freispeichers definiert. Während der Laufzeit wird die Größe des Freispeichers üblicherweise erhöht und kann von der JVM nicht verkleinert werden.
Bei dem vorstehend erwähnten Szenario weist das BS der JVM wie jedem Gastprozess einen Teil des physischen Speichers zu. Wenn die JVM mehr Speicher nutzt als physischer Speicher verfügbar ist, beginnt das BS mit dem Auslagern von Benutzerbereichsspeicher (user space memory) auf die Festplatte oder ähnliche externe Einheiten. Durch diesen Prozess wird die Leistungsfähigkeit der JVM und des gesamten Systems beträchtlich verringert. Bei einigen Realisierungen, wenn mehrere VMs auf einem einzigen Host laufen und gemeinsam eine feste Menge physischen Speichers nutzen, kann der Hypervisor Speicher überbelegen, um die Kosten zu verringern, indem er den VMs die Illusion vermittelt, sie hätten mehr Speicher als tatsächlich auf der physischen Maschine zur Verfügung steht.
Aufgrund der Tatsache, dass kein Zusammenwirken zwischen der JVM und dem Hypervisor stattfindet, erfolgt, wenn eine JVM in einer VM ausgeführt wird und die Größe des Freispeichers der JVM den von dem Hypervisor zugewiesenen physischen Speicher übersteigt, auf der Host- oder der Gastebene eine Auslagerung, wodurch die Leistung der VM und des gesamten Hosts ebenfalls verringert wird. Es gibt einen bekannten Ausgleich (trade-off) zwischen der Leistung der JVM und der Größe des Freispeichers. Obwohl durch das Verkleinern der Größe des Freispeichers die Leistung der JVM verringert wird, ist diese Leistungsverschlechterung um eine Größenordnung geringer als die Leistungsverschlechterung, wenn die Größe des Freispeichers den zur Verfügung stehenden physischen Speicher übersteigt.
KURZDARSTELLUNG
Gemäß einer Ausführungsform wird ein Speicherverwaltungsverfahren in einer virtualisierten Datenverarbeitungsumgebung bereitgestellt, bei dem ein Hypervisor mindestens eine virtuelle Maschine (VM) auf einer Hostmaschine realisiert, wobei ein Gastbetriebssystem (BS) auf der VM ausgeführt wird und eine Anwendung, die Speicherverwaltungsfähigkeiten unterstützt, auf dem Gast-BS ausgeführt wird. Das Verfahren weist das Aufrufen eines ersten, von der Anwendung realisierten Speichermanagers (java balloon („Java-Balloon”)) auf, zwecks Aufhebens der Zuordnung von der Anwendung zugeordnetem Speicher zur Verwendung durch den Hypervisor, als Reaktion auf eine von dem Hypervisor gesendete Anforderung, sowie das Aufrufen eines zweiten, auf dem Gastbetriebssystem realisierten Speichermanagers (guest balloon („Gast-Balloon”)), zwecks Aufhebens der Zuordnung von dem Gast-BS zugeordnetem Speicher, als Reaktion auf eine von dem Hypervisor gesendete Anforderung.
Gemäß einer oder mehreren Ausführungsformen wird ein System mit einer oder mehreren Logikeinheiten bereitgestellt. Die Logikeinheit(en) sind dafür konfiguriert, die mit den vorstehend offenbarten Verfahren in Verbindung stehenden Funktionen und Operationen auszuführen. Bei einer noch anderen Ausführungsform wird ein Computerprogrammprodukt bereitgestellt, das ein computerlesbares Speichermedium mit einem computerlesbaren Programm aufweist. Wenn das computerlesbare Programm auf einem Computer ausgeführt wird, veranlasst es den Computer dazu, die mit den vorstehend offenbarten Verfahren in Verbindung stehenden Funktionen und Operationen auszuführen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Im Folgenden wird eine bevorzugte Ausführungsform der vorliegenden Erfindung ausschließlich beispielhaft unter Bezugnahme auf die begleitenden Zeichnungen beschrieben:
Die 1 veranschaulicht eine beispielhafte Betriebsumgebung gemäß einer oder mehreren Ausführungsformen, wobei eine Vielzahl von VMs in einer virtualisierten Datenverarbeitungsumgebung ausgeführt wird.
Die 2 ist ein beispielhaftes Blockschaubild einer Datenstruktur, die zum dynamischen Zuordnen von Speicher in einer virtualisierten Umgebung genutzt wird, gemäß einer beispielhaften Ausführungsform, bei der eine JVM in einem Gast ausgeführt wird.
Die 3A und 3B sind Ablaufpläne beispielhafter Verfahren zum dynamischen Zuordnen von Speicher und zum dynamischen Aufheben der Zuordnung gemäß einer Ausführungsform.
Die 4A und 4B sind Blockschaubilder von Hardware- und Softwareumgebungen gemäß einer oder mehreren Ausführungsformen, in denen die offenbarten Systeme und Verfahren betrieben werden können.
Funktionen, Elemente und Aspekte, auf die in verschiedenen Figuren durch dieselben Bezugszeichen verwiesen wird, repräsentieren dieselben, gleichwertige oder ähnliche Merkmale, Elemente oder Aspekte gemäß einer oder mehreren Ausführungsformen.
AUSFÜHRLICHE BESCHREIBUNG BEISPIELHAFTER AUSFÜHRUNGSFORMEN
Mit Bezug auf die 1: Bei einer Ausführungsform wird eine beispielhafte Laufzeit-Datenverarbeitungsumgebung veranschaulicht. Wie gezeigt, weist eine Betriebsumgebung 110 einen Hypervisor 112 auf, der auf einer Hostmaschine 100 läuft. Der Hypervisor 112 dient im Grunde als ein Betriebssystem (BS) der Hostmaschine 100 und stellt eine Laufzeitumgebung für eine oder mehrere virtuelle Maschinen (VMs) bereit. Daher unterstützt die Betriebsumgebung 110 ein virtualisiertes System, bei dem beispielhafte VMs 120 und 130 auf dem Hypervisor 112 ausgeführt werden können.
Die VMs 120 und 130 können ein oder mehrere Gastsoftwareprogramme (z. B. die Anwendungen 126, 136) hosten, die auf dem Gast-BS 124 oder 134 laufen. Wie in 2 gezeigt, kann Speicher der oder den Gastanwendungen 126, 136 und dem Hypervisor 112 zugeordnet werden. Der Hypervisor 112 weist den VMs 120 und 130 Speicher aus freiem Speicherplatz (nicht gezeigt) zu, der auf der Hostmaschine 100 zur Verfügung steht. Das Gast-BS 124 ordnet einen Teil des Speichers einer Speicherverwaltungs-Datenstruktur der Anwendung 126 zu. Ein Teil des Speichers in der Speicherverwaltungs-Datenstruktur kann mithilfe einer oder mehrerer Vorab-Speicherreservierungsmechanismen (d. h. der Anwendungs-Balloon 280) reserviert sein, wie es nachfolgend ausführlicher beschrieben wird.
Mit Bezug auf die 2: Bei einer beispielhaften Ausführungsform kann die Anwendung 126 eine Java Virtual Machine (JVM) sein, und die Speicherverwaltungs-Datenstruktur kann als ein Freispeicher 222 realisiert sein, der einen Pool von Speicher enthält, der in einem freien Bereich 260 des Freispeichers zur Verfügung steht. Ein hier als „Gast-Ballooning” (guest ballooning) bezeichneter Prozess kann dazu verwendet werden, ein Gast-BS 124 von dem geringen verfügbaren Speicher einer Hostmaschine 100 (d. h. dem Bedarf des Hypervisors 112 an zusätzlichem Speicher) in Kenntnis zu setzen. Bei einer Ausführungsform tauscht der Hypervisor 112 mit dem VM-Balloon-Treiber 230 (d. h. dem Gast-Balloon-Treiber) oder dem Anwendungs-Balloon 280 oder beiden Daten aus, wenn der Hypervisor 112 Speicher zurückfordern muss. Abhängig von der Realisierung kann der Hypervisor 112 eine Ziel-Balloon-Größe für den VM-Balloon-Treiber 230 festlegen, damit ein Balloon eines Gast-BS 124 dekomprimiert wird, indem er beispielsweise physische Seiten des Gasts in dem Gast-BS 124 zuordnet.
Bei einer Realisierung dekomprimiert der Hypervisor 112 den Balloon des Gast-BS 124 gemäß einer oder mehreren Speicherverwaltungsrichtlinien (z. B., wenn bei dem Hypervisor 112 ein Speicherengpass auftritt). Durch Dekomprimieren des Gast-Balloons verwaltet der Hypervisor 112 die Speicherverwaltung so, dass die Ziele der realisierten Richtlinien erreicht werden (z. B. durch Übertragen des Speicherengpasses von der Hostmaschine 100 auf das Gast-BS 124). Als Reaktion darauf ordnet der VM-Balloon-Treiber 230 physischen Speicher des Gasts zu und fixiert diesen Speicher möglicherweise. Das Gast-BS 124 ermittelt, ob das BS physischen Speicher des Gasts auslagern muss, um die Zuordnungsanforderungen des VM-Balloon-Treibers 230 zu erfüllen.
Wenn der Gast über viel freien physischen Gastspeicher verfügt, löst das Dekomprimieren des Gast-Balloons kein Auslagern aus und beeinträchtigt die Leistung des Gasts nicht. Wenn bei dem Gast jedoch bereits ein Speicherengpass vorliegt, entscheidet das Gast-BS 124, welche physischen Seiten des Gasts in die virtuelle Auslagerungseinheit ausgelagert werden, um die Zuordnungsanforderungen des Balloon-Treibers zu erfüllen. Dieser Gast-Ballooning-Mechanismus ermöglicht es dem Gast-BS 124 daher, ohne Einbeziehen des Hypervisors 112 eine intelligente Entscheidung darüber zu treffen, welche Seiten ausgelagert werden sollen.
In den Fällen, bei denen der vorstehend erwähnte Gast-Ballooning-Mechanismus nicht ausreichend für das Zurückfordern von Speicher ist, kann der Hypervisor 112 gezwungen sein, für das Gast-BS 124 eine getrennte Auslagerungsdatei zu erstellen, so dass der Hypervisor physischen Speicher des Gasts direkt in diese Auslagerungsdatei auslagern kann, wodurch physischer Speicher des Hosts für andere Gäste freigegeben wird. Bei einer Ausführungsform kann ein zweiter Balloon-Mechanismus (zusätzlich zu dem vorstehenden Gast-Balloon-Mechanismus oder ausschließlich des vorstehenden Gast-Balloon-Mechanismus) genutzt werden, um für das Entziehen oder Freigeben von Speicher aus einer Speicherverwaltungs-Datenstruktur (z. B. im Fall der JVM der Freispeicher 222) zu sorgen, um einem laufenden Gast-BS 124 Speicher zuzuordnen oder die Zuordnung von Speicher aufzuheben.
Als Überblick: Dieser zweite Ballooning-Mechanismus kann bei einer Ausführungsform dazu verwendet werden, einen Teil des Speichers in dem Freispeicher 222 Balloon-Objekten zuzuordnen, von denen das Betriebssystem eines Gasts (z. B. das Gast-BS 124) eine Instanz erstellt hat. Im Folgenden wird der zweite Ballooning-Mechanismus beispielhaft in einer Realisierung offenbart, bei der er auf ein Gast-BS angewendet werden soll, das auf einer JVM läuft. Daher werden die Balloon-Objekte als Java-Balloon-Objekte 210 bezeichnet (siehe 2).
Es sollte jedoch beachtet werden, dass die hier offenbarten Konzepte und Mechanismen auf andere virtuelle Maschinen als JVMs oder in anderen virtualisierten Umgebungen als JVMs angewendet werden können. Daher soll der Schutzumfang der Ansprüche nicht so verstanden werden, dass er in enggefasster Form auf die Ausführungsformen anwendbar wäre, die hier in Verbindung mit JVMs oder anderen beispielhaften Merkmalen oder Mechanismen offenbart werden, die realisiert werden, um in der JVM-Umgebung betrieben zu werden, wie beispielsweise der Freispeicher 222. Trotzdem wird beispielsweise aus Gründen der Einheitlichkeit der zweite Balloon-Mechanismus als der Java-Balloon bezeichnet. Daher sind die hier offenbarten Konzepte auf andere Anwendungen anwendbar, die in der Lage sind, das Zuordnen von Speicher in einer Speicherverwaltungs-Datenstruktur wie beispielsweise dem Freispeicher 222 zu verwalten.
Mit Bezug auf die 1 und 2: Der Zweck der Java-Balloon-Objekte besteht darin, als Platzhalter zu dienen, so dass die JVM oder ein von der JVM gehosteter Prozess nicht den den Java-Balloon-Objekten 210 zugeordneten Speicherplatz verwenden. Auf diese Weise kann, wenn der Hypervisor 112 zusätzlichen Speicher benötigt (zum Beispiel, um ihn anderen auf der Hostmaschine 100 laufenden VMs oder Prozessen zuzuordnen), der von den Java-Balloon-Objekten 210 reservierte Speicherplatz für das Gast-BS 124 und schließlich für den Hypervisor 112 freigegeben werden, wie es nachfolgend ausführlicher beschrieben wird.
Bei einer Ausführungsform dekomprimiert oder komprimiert die JVM den so genannten Java-Balloon durch Zuordnen von mehr oder weniger Speicher zu den Java-Balloon-Objekten 210. Begrifflich ist mit dem Java-Balloon ein Teil des Freispeichers 222 gemeint, der den Java-Balloon-Objekten 210 zugeordnet ist, um Speicherplatz für den Hypervisor 112 zu reservieren oder dem Gast-BS 124 ungenutzten Speicher 220 zur Verfügung zu stellen. Der Rest des freien Speicherplatzes 260 des Freispeichers kann für reguläre Objekte 200 zur Verfügung gestellt werden, von denen die JVM (d. h. die Anwendung 126) zu anderen Zwecken eine Instanz erstellt.
Mithilfe des Java-Balloon-Mechanismus können die anderen Prozesse und Anwendungen nicht auf den den Java-Balloon-Objekten 210 zugeordneten Speicherplatz zugreifen. Außerdem kann das Gast-BS 124 sein Kontingent nicht überschreiten, wenn der von den Java-Balloon-Objekten 210 reservierte Speicher für den Hypervisor 112 freigegeben wird. Bei einer Ausführungsform können die Java-Balloon-Objekte 210 in der JVM fixiert sein, so dass die Java-Balloon-Objekte 210 nicht in dem Freispeicher 222 verschoben werden, beispielsweise als Folge eines Garbage-Collection-Prozesses.
Bei einer Ausführungsform dient der Java-Balloon als ein Thread in dem JVM-Benutzerbereichsprozess und beschafft Java-Balloon-Objekte 210 oder gibt sie frei, um die Größe des Freispeichers zu verändern. Wie bereits angemerkt, löst der vorstehend erörterte Gast-Balloon-Mechanismus nicht das Speicherüberbelegungsproblem bei VMs, die Arbeitslasten auf der Grundlage von Java ausführen, da das Gast-BS möglicherweise häufig Auslagerungen vornimmt, wenn die Größe des Freispeichers der JVM die Menge physischen Speichers übersteigt, der aktuell der VM zu gewiesen ist.
Durch Verwenden des Java-Balloon (z. B. optional in Verbindung mit den Gast-Balloon-Mechanismen) kann der Hypervisor 112 sowohl die einem Gast-BS 124 zugewiesene Menge physischen Speichers als auch die Speicheranforderungen der Anwendung 126 (z. B. der JVM-Prozess) steuern, die auf dem Gast-BS 124 ausgeführt wird. Kurz gesagt, der Hypervisor 112 verwendet den Java-Balloon dazu, die Größe des Freispeichers der JVM unter der Größe des physischen Speichers der VM zu halten. Auf diese Weise kann Java-Anwendungscode oder Bytecode unverändert bleiben, wenn ein Java-Balloon in der JVM verwendet wird, wie es nachfolgend ausführlicher beschrieben wird.
Mit Bezug auf die 2 und 3A: Der Java-Balloon kann bei einer Ausführungsform mithilfe eines einzigen oder mehrerer Java-Balloon-Objekte 210 (z. B. primitive Byte-Arrays) realisiert werden, die Speicherplatz in dem Freispeicher 222 in Anspruch nehmen. Wenn der Hypervisor 112 fordert, dass einer Anwendung Speicher entzogen werden soll, wird der Java-Balloon aufgerufen (S310). Der Java-Balloon wird durch Beschaffen von Speicher aus dem Speicherbereich der Anwendung dekomprimiert (z. B. Zuordnen neuer Java-Balloon-Objekte 210 in dem Freispeicher) und Beibehalten ihrer Verweise (S320). Bei einer Ausführungsform können, beispielsweise unter Verwendung der nativen Java-Schnittstelle Java Native Interface (JNI), die Java-Balloon-Objekte 210 in dem Speicher fixiert werden, um zu verhindern, dass sie durch einen Garbage-Collector-Prozess verschoben werden.
Ein Prozedur- oder Betriebssystemaufruf kann verwendet werden, um zu überwachen, ob der den Java-Balloon-Objekten 210 zugeordnete Speicher für das Gast-BS 124 freigegeben werden kann (S330). Bei einer Realisierung können die nativen Verweise (z. B. die virtuellen Adressen) der Objekte verwendet werden, um das Gast-BS 124 davon in Kenntnis zu setzen, dass der den Java-Balloon-Objekten 210 entsprechende Speicher nicht mehr benötigt wird. Beispielsweise kann bei Verwenden des Betriebssystemaufrufs madvise() in Linux der Speicher an das Gast-BS 124 zurückgegeben werden (S340). Der VM-Balloon-Treiber 230 des Gast-BS 124 kann dazu verwendet werden, dem Gast-BS 124 Speicher zu entziehen, indem gemäß den vorstehend erwähnten Prozessen (d. h. S320 bis S340) nach dem Dekomprimieren des Java-Balloons der Gast-Balloon dekomprimiert wird (S350).
Im Gegensatz zu der 3A veranschaulicht die 3B gemäß einer Ausführungsform ein Verfahren zum Zurückgeben von Speicher an das Gast-BS 124, wenn der Speicher nicht mehr von dem Hypervisor 112 benötigt wird. Wie gezeigt kann der VM-Balloon-Treiber 230 des Gast-BS 124 von dem Hypervisor 112 aufgerufen werden, um den Gast-Balloon vor dem Komprimieren des Java-Balloon zu komprimieren (S360), wie es nachfolgend ausführlicher beschrieben wird.
Bei einer Ausführungsform kann der Hypervisor 112 anfordern, dass der Java-Balloon den Java-Balloon-Objekten 210 zugeordneten Speicher an den Speicherbereich der Anwendung (z. B. der Freispeicher 222) zurückgibt (S370). Der Hypervisor 112 ruft den Java-Balloon auf, damit dieser komprimiert wird und der für das vorstehend offenbarte Gast-BS 124 freigegebene Speicher an den JVM-Freispeicher 222 übertragen wird. Der Java-Balloon prüft, ob beim Dekomprimieren des Java-Balloon Speicher für das Gast-BS 124 freigegeben wurde (S380). Wenn dies zutrifft, wird der den Java-Balloon-Objekten zugeordnete Speicher von dem Gast-BS 124 beschafft (S390). Der Java-Balloon gibt alle Verweise auf die Java-Balloon-Objekte frei, so dass sie von dem Gast-BS 124 als freier Speicherplatz behandelt werden und in dem freien Speicherplatz der Anwendung für andere Zwecke verwendet werden können (S395).
Im Folgenden wird der mit dem Dekomprimieren und Komprimieren des Java-Balloon verbundene Prozess ausführlicher erörtert, wobei auf beispielhafte Ausführungsformen Bezug genommen wird, die in einer JVM mit einem eingebetteten Java-Balloon auf einem Linux-BS realisiert sind. Bei einer solchen Realisierung wird der Eintrittspunkt der Anwendung der JVM als Laufzeitparameter übergeben. Der Eintrittspunkt kann gegen einen neuen ausgetauscht werden, der den ursprünglichen Eintrittspunkt als einen Befehlszeilenparameter erhält. Der neue Eintrittspunkt startet einen Dämon-Thread, der zuständig für das Erstellen des Java-Balloon in einer ursprünglichen Größe ist (kann als ein Befehlszeilenparameter angegeben werden), und beginnt anschließend mit dem Ausführen des ursprünglichen Eintrittspunkts. Der Dämon-Thread bleibt für die Dauer des JVM-Prozesses aktiv und wartet auf externe Anforderungen, die Größe des Java-Balloon zu vergrößern oder zu verkleinern. Dies kann mithilfe von TCP-Sockets oder einem beliebigen anderen Prozess-Datenübertragungsmechanismus vorgenommen werden. Jedes Mal, wenn der Dämon-Thread eine Anforderung erhält, dekomprimiert oder komprimiert er den Java-Balloon dementsprechend, indem er Objekte freigibt oder neue beschafft.
Dekomprimieren des Java-Balloon: Wenn der Balloon-Dämon eine Anforderung erhält, den Java-Balloon zu dekomprimieren, beginnt er mit dem Erstellen neuer Objekte, bis der Java-Balloon die entsprechende Größe erreicht. Wenn die Größe des Balloon beispielsweise 100 MB beträgt und der Dämon eine Anforderung erhält, den Balloon auf 300 MB zu dekomprimieren, erstellt der Dämon neue Objekte, die 200 MB in dem Freispeicher in Anspruch nehmen, und behält die Verweise bei. Bei diesen Objekten kann es sich beispielsweise um primitive Byte-Arrays handeln. Anschließend werden die Objekte unter Verwendung von JNI-Diensten in dem Speicher fixiert (z. B. Aufrufen von GetPrimitiveArrayCritical). Schließlich wird der entsprechende Speicher für das BS freigegeben, beispielsweise durch Aufrufen des Betriebssystemaufrufs madvise für Linux mit dem Merker MADV_DONTNEEDED.
Komprimieren des Java-Balloon: Wenn der Balloon-Dämon eine Anforderung erhält, den Java-Balloon zu komprimieren, fordert er die entsprechende Menge an Speicher von dem BS zurück, beispielsweise durch Aufrufen des Betriebssystemaufrufs madvise für Linux mit dem Merker MADV_NORMAL. Anschließend hebt der Dämon die Fixierung der entsprechenden Objekte auf (z. B. Aufrufen von ReleasePrimitiveArrayCritical). Die Verweise auf die entsprechenden Objekte werden freigegeben, indem es dem Garbage-Collector der JVM gestattet, diese zu finden und als freien Speicherplatz zu behandeln.
Die vorstehenden Angaben können sich ändern, wenn die JVM langfristiges Fixieren nicht unterstützt. Wenn die JVM beispielsweise langfristiges Fixieren nicht unterstützt, dafür aber das Deaktivieren der Komprimierung, kann die JVM ohne Komprimierung gestartet werden, und der Java-Balloon fixiert keine Objekte. Wenn die JVM weder langfristiges Fixieren noch das Deaktivieren der Komprimierung unterstützt, fixiert der Java-Balloon die Objekte nicht und setzt das BS auch nicht über diese Objekte in Kenntnis. Nach einer gewissen Zeit werden die Java-Balloon-Objekte komprimiert und bleiben an einem gleichbleibendem Platz in dem Freispeicher. Das BS erkennt dann, dass die den Java-Balloon-Objekten entsprechenden Seiten nicht verwendet werden, und lagert sie auf die Festplatte aus.
Die vorstehend erwähnten Verfahren können auf andere Nicht-JVM-Umgebungen und Programme anwendbar sein, die beispielsweise ihre eigene Speicherverwaltung realisieren, so dass (1) das Programm das Ausführen eines Moduls/Codes in demselben Speicherzusammenhang gestattet (z. B. Plug-ins), (2) das Programm eine Schnittstelle zum Beschaffen und Freigeben von Speicher zugänglich macht, oder (3) das Programm eine Schnittstelle für den Datenaustausch mit externen Entitäten zugänglich macht. Wenn die vorstehend erwähnten optionalen Bedingungen nicht vorhanden sind, kann der Balloon-Mechanismus mit einer integrierten autonomen Richtlinie zum Steuern der Balloon-Größe verwendet werden.
Bei anderen Ausführungsformen kann der beanspruchte Gegenstand als eine Kombination von Hardware- und Softwareelementen oder alternativ entweder vollständig in Form von Hardware oder vollständig in Form von Software realisiert werden. Außerdem können hier offenbarte Datenverarbeitungssysteme und Programmsoftware eine gesteuerte Datenverarbeitungsumgebung aufweisen, die in Form von Hardwarekomponenten oder Logikcode präsentiert werden kann, der zum Durchführen der Verfahren und Prozesse ausgeführt wird, mit deren Hilfe die hier in Betracht gezogenen Ergebnisse erzielt werden. Mithilfe dieser Verfahren und Prozesse wird, wenn diese von einem Allzweck-Datenverarbeitungssystem oder einer derartigen Maschine ausgeführt werden, die Allzweckmaschine in eine Spezialmaschine umgewandelt.
Mit Bezug auf die 4A und 4B: Eine Datenverarbeitungssystem-Umgebung gemäß einer beispielhaften Ausführungsform kann aus einer Hardwareumgebung 1110 und einer Softwareumgebung 1120 bestehen. Die Hardwareumgebung 1110 kann Logikeinheiten, Schaltungen oder andere Maschinen und Geräte aufweisen, mit deren Hilfe eine Ausführungsumgebung für die Komponenten der Softwareumgebung 1120 bereitgestellt wird. Die Softwareumgebung 1120 kann wiederum die Ausführungsanweisungen, darunter die zugrunde liegenden Betriebseinstellungen und -konfigurationen, für die verschiedenen Komponenten der Hardwareumgebung 1110 bereitstellen.
Mit Bezug auf die 4A: Die hier offenbarte Anwendungssoftware und der hier offenbarte Logikcode können in der Form von computerlesbarem Code realisiert sein, der auf einem oder mehreren Datenverarbeitungssystemen, repräsentiert durch die beispielhafte Hardwareumgebung 1110, hinweg ausgeführt wird. Wie veranschaulicht, kann die Hardwareumgebung 110 einen Prozessor 1101 aufweisen, der mithilfe eines Systembusses 1100 mit einem oder mehreren Speicherelementen verbunden ist. Die Speicherelemente können beispielsweise lokalen Speicher 1102, ein Speichermedium 1106, Cachespeicher 1104 oder andere computerverwendbare oder computerlesbare Medien aufweisen. Im Zusammenhang dieser Offenbarung kann es sich bei einem computerverwendbaren oder computerlesbaren Speichermedium um einen beliebigen beschreibbaren Gegenstand handeln, der zum Enthalten, Speichern, Übermitteln, Verbreiten oder Transportieren von Programmcode verwendet werden kann.
Ein computerlesbares Speichermedium kann ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitermedium, ein derartiges System, eine derartige Vorrichtung oder Einheit sein. Das computerlesbare Speichermedium kann auch ohne Einschränkung in einem Verbreitungsmedium realisiert sein, in dem Ausmaß, dass eine solche Realisierung als satzungsgemäß vorgeschriebener Gegenstand angesehen wird. Beispiele für ein computerlesbares Speichermedium können unter anderem gegebenenfalls ein Halbleiter- oder Festkörperspeicher, ein Magnetband, eine entnehmbare Computerdiskette, ein Speicher mit wahlfreiem Zugriff (RAM), ein Nur-Lese-Speicher (ROM), eine starre Magnetplatte, eine optische Platte oder eine Trägerwelle sein. Zu aktuellen Beispielen für optische Platten zählen unter anderem Compact Disk, Nur-Lese-Speicher (CD-ROM), Compact Disk, Lesen/Schreiben (CD-R/W), digitale Videoplatten (DVD), hochauflösende Videoplatten (HD-DVD) oder Blue-ray^TM-Platten.
Bei einer Ausführungsform lädt der Prozessor 1101 ausführbaren Code aus dem Speichermedium 1106 in den lokalen Speicher 1102. Der Cachespeicher 1104 optimiert die Verarbeitungszeit durch Bereitstellen von temporärem Speicherplatz, was dazu beiträgt, die Häufigkeit zu verringern, mit der Code zum Ausführen geladen wird. Eine oder mehrere Benutzerschnittstelleneinheiten 1105 (z. B. Tastatur, Zeigeeinheit usw.) sowie ein Bildschirm 1107 können mit den anderen Elementen in der Hardwareumgebung 1110 entweder direkt oder beispielsweise über einen dazwischen angeordneten E/A-Controller 1103 verbunden sein. Eine Datenübertragungs-Schnittstelleneinheit 1108, beispielsweise ein Netzwerk-Adapter, kann bereitgestellt werden, um die Hardwareumgebung 1110 in die Lage zu versetzen, mit lokal oder entfernt angeordneten Datenverarbeitungssystemen, Druckern und Speichereinheiten über dazwischen angeordnete private oder öffentliche Netzwerke (z. B. das Internet) Daten auszutauschen. Kabelgebundene oder kabellose Modems sowie Ethernet-Karten sind einige der beispielhaften Arten von Netzwerkadaptern.
Es sollte beachtet werden, dass die Hardwareumgebung 1110 bei bestimmten Realisierungen möglicherweise einige oder alle der vorstehend genannten Komponenten nicht enthält oder weitere Komponenten enthalten kann, um Zusatzfunktionen oder Zusatznutzen zu bieten. Abhängig von der in Betracht gezogenen Verwendung und Konfiguration, kann die Hardwareumgebung 1110 ein Desktop- oder ein Laptop-Computer oder eine andere Datenverarbeitungseinheit sein, die optional in einem eingebetteten System wie beispielsweise einer Set-Top-Box, einem persönlichen digitalen Assistenten (PDA), einem persönlichen Medienabspieler, einer mobilen Datenübertragungseinheit (z. B. einem Funktelefon) oder anderen ähnlichen Hardwareplattformen mit Datenverarbeitungs- oder Datenspeicherfähigkeiten verkörpert sein kann.
Bei einigen Ausführungsformen dient die Datenübertragungsschnittstelle 1108 als ein Datenübertragungsanschluss, damit Mittel zum Übertragen von Daten mit einem oder mehreren Datenverarbeitungssystemen durch Senden und Empfangen digitaler, elektrischer, elektromagnetischer oder optischer Signale bereitgestellt werden, die analoge oder digitale Datenströme führen, die verschiedene Arten von Daten repräsentieren, darunter Programmcode. Die Datenübertragung kann mithilfe eines lokalen oder entfernt angeordneten Netzwerks oder alternativ mithilfe von Übertragung über die Luft oder ein anderes Medium eingerichtet werden, darunter ohne Einschränkung das Verbreiten über eine Trägerwelle.
Die hier bereitgestellten, offenbarten Softwareelemente, die auf den veranschaulichten Hardwareelementen ausgeführt werden, sind gemäß logischen oder funktionalen Beziehungen definiert, die ihrem Wesen nach beispielhaft sind. Es sollte jedoch beachtet werden, dass die jeweiligen Verfahren, die mithilfe der beispielhaften Softwareelemente realisiert werden, auch in den Hardwareelementen codiert sein können, und zwar beispielsweise mithilfe konfigurierter und programmierter Prozessoren, anwendungsspezifischer integrierter Schaltungen (application specific integrated circuits, ASICs), feldprogrammierbarer Gate-Arrays (field programmable gate arrays, FPGAs) sowie digitaler Signalprozessoren (digital signal processors, DSPs).
Mit Bezug auf die 4B: Die Softwareumgebung 1120 kann allgemein in zwei Klassen unterteilt werden, die Systemsoftware 1121 und die Anwendungssoftware 1122, die in einer oder mehreren Hardwareumgebungen 1110 ausgeführt werden. Bei einer Ausführungsform können die hier offenbarten Verfahren und Prozesse als Systemsoftware 1121, Anwendungssoftware 1122 oder eine Kombination davon realisiert sein. Die Systemsoftware 1121 kann Steuerprogramme wie beispielsweise ein Betriebssystem (BS) oder ein Datenverwaltungssystem aufweisen, die einem oder mehreren Prozessoren 1101 (z. B. Mikrocontrollern) in der Hardwareumgebung 1110 Anweisungen darüber erteilen, wie sie arbeiten und Daten verarbeiten sollen. Die Anwendungssoftware 1122 kann, aber ohne darauf beschränkt zu sein, Programmcode, Datenstrukturen, Firmware, speicherresidente Software, Mikrocode oder jede andere Form von Daten oder Routinen aufweisen, die von einem Prozessor 1101 gelesen, analysiert oder ausgeführt werden können.
Mit anderen Worten: Die Anwendungssoftware 1122 kann als in einem Computerprogrammprodukt eingebetteter Programmcode in Form eines computerverwendbaren oder computerlesbaren Speichermediums realisiert sein, das Programmcode zur Verwendung durch einen Computer oder ein beliebiges Anweisungsausführungssystem oder in Verbindung mit diesen bereitstellt. Außerdem kann die Anwendungssoftware 1122 ein oder mehrere Computerprogramme aufweisen, die nach dem Laden aus dem Speichermedium 1106 in den lokalen Speicher 1102 auf der Systemsoftware 1121 ausgeführt werden. Bei einer Client-Server-Architektur kann die Anwendungssoftware 1122 Clientsoftware und Serversoftware aufweisen. Beispielsweise kann die Clientsoftware bei einer Ausführungsform auf einem Client-Datenverarbeitungssystem ausgeführt werden, das verschieden und trennbar von einem Server-Datenverarbeitungssystem ist, auf dem Serversoftware ausgeführt wird.
Die Softwareumgebung 1120 kann außerdem eine Browsersoftware 1126 zum Zugriff auf Daten aufweisen, die über lokale oder entfernt angeordnete Datenverarbeitungs-Netzwerke zur Verfügung stehen. Die Softwareumgebung 1120 kann außerdem eine Benutzerschnittstelle 1124 (z. B. eine grafische Benutzerschnittstelle, graphical user interface (GUI)) zum Empfangen von Benutzerbefehlen und Daten aufweisen. Es sollte weiterhin beachtet werden, dass die vorstehend beschriebenen Hardware- und Softwarearchitekturen und -umgebungen lediglich als Beispiele dienen. Als solche können eine oder mehrere Ausführungsformen auf jeder Art von Systemarchitektur, funktionaler oder logischer Plattform oder Verarbeitungsumgebung realisiert werden.
Es sollte außerdem beachtet werden, dass der Logikcode, Programme, Module, Prozesse, Verfahren sowie die Reihenfolge, in der die entsprechenden Prozesse jedes Verfahrens ausgeführt werden, lediglich beispielhaft sind. Abhängig von der Realisierung können die Prozesse oder jegliche zugrunde liegenden Teilprozesse und -verfahren in jeder beliebigen Reihenfolge oder gleichzeitig ausgeführt werden, so lange dies in der vorliegenden Offenbarung nicht anders angegeben ist. Außerdem ist im Zusammenhang dieser Offenbarung, soweit konkret nicht anders angegeben, die Definition von Logikcode nicht auf irgendeine bestimmte Programmiersprache bezogen oder beschränkt und kann ein oder mehrere Module aufweisen, die auf einem oder mehreren Prozessoren in verteilten oder nicht verteilten Umgebungen mit einem oder mehreren Prozessoren ausgeführt werden können.
Wie Fachleute verstehen werden, kann eine Softwareausführungsform Firmware, speicherresidente Software, Mikrocode usw. enthalten. Bestimmte Komponenten, darunter Software oder Hardware oder eine Kombination von Software- und Hardwareaspekten können hier allgemein als eine „Schaltung”, ein „Modul” oder ein „System” bezeichnet sein. Der hier offenbarte Gegenstand kann außerdem als ein Computerprogrammprodukt realisiert sein, das in einem oder mehreren computerlesbaren Speichermedien mit in dem Medium enthaltenem computerlesbarem Programmcode verkörpert ist. Es kann eine beliebige Kombination von einem oder mehreren computerlesbaren Speichermedien verwendet werden. Das computerlesbare Speichermedium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann beispielsweise, aber ohne darauf beschränkt zu sein, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine derartige Vorrichtung oder Einheit oder jede beliebige Kombination von diesen sein.
Im Zusammenhang dieses Dokuments kann ein computerlesbares Speichermedium ein beliebiges physisches Medium sein, das ein Programm für die Nutzung durch ein Anweisungen ausführendes System, eine solche Vorrichtung oder Einheit oder für die Nutzung in Verbindung mit einem Anweisungen ausführenden System, einer solchen Vorrichtung oder Einheit enthalten oder speichern kann. Ein computerlesbares Signalmedium kann unter anderem ein verbreitetes Datensignal mit darin enthaltenem computerlesbarem Programmcode sein, zum Beispiel im Basisband oder als Teil einer Trägerwelle. Ein solches verbreitetes Signal kann verschiedene Formen annehmen, unter anderem, aber ohne darauf beschränkt zu sein, eine elektromagnetische oder optische Form oder eine beliebige Kombination von diesen. Ein computerlesbares Signalmedium kann jedes computerlesbare Medium sein, das kein computerlesbares Speichermedium ist und das ein Programm für die Nutzung durch ein Anweisungen ausführendes System, eine solche Vorrichtung oder Einheit oder für die Nutzung in Verbindung mit einem Anweisungen ausführenden System, einer solchen Vorrichtung oder Einheit übermitteln, verbreiten oder transportieren kann.
Auf einem computerlesbaren Speichermedium enthaltener Programmcode kann mithilfe jedes geeigneten Mediums übermittelt werden, einschließlich, ohne darauf beschränkt zu sein, ein drahtloses oder drahtgebundenes Medium, Lichtwellenleiterkabel, HF (Hochfrequenz) usw. oder jede geeignete Kombination von diesen. Computerprogrammcode zum Ausführen der offenbarten Operationen kann in einer beliebigen Kombination einer oder mehrerer Programmiersprachen geschrieben sein, darunter eine objektorientierte Programmiersprache wie Java, Smalltalk, C++ oder Ähnliche sowie herkömmliche prozedurale Programmiersprachen wie beispielsweise die Programmiersprache „C” oder ähnliche Programmiersprachen.
Der Programmcode kann vollständig oder teilweise auf dem Computer des Benutzers, als ein eigenständiges Softwarepaket, zum Teil auf dem Computer des Benutzers und zum Teil auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. Bei dem letzteren Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch ein beliebiges Netzwerk, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN) verbunden sein, oder es kann eine Verbindung mit einem externen Computer hergestellt werden (zum Beispiel mithilfe eines Internetdienstanbieters über das Internet).
Bestimmte Ausführungsformen werden mit Bezug auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen offenbart. Es versteht sich, dass jeder Block der Ablaufpläne und/oder Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder Blockschaubildern durch Computerprogrammanweisungen realisiert werden können. Diese Computerprogrammanweisungen können für einen Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung zur Herstellung einer Maschine bereitgestellt werden, so dass die Anweisungen, die durch den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Realisieren der in dem Block oder den Blöcken des Ablaufplans und/oder Blockschaubilds angegebenen Funktionen/Handlungen erzeugen.
Diese Computerprogrammanweisungen können auch in einem computerlesbaren Speichermedium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Weise funktionieren, so dass die in dem computerlesbaren Speichermedium gespeicherten Anweisungen ein Erzeugnis samt der Anweisungen herstellen, mit deren Hilfe die in dem Block oder den Blöcken des Ablaufplans und/oder Blockschaubilds angegebene Funktion/Handlung realisiert wird.
Die Computerprogrammanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um eine Reihe von auf dem Computer, der anderen programmierbaren Vorrichtung oder den anderen Einheiten auszuführenden Betriebsschritten zu bewirken, um einen computerrealisierten Prozess zu schaffen, so dass die Anweisungen, die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführt werden, Verfahren zum Realisieren der in dem Block oder den Blöcken des Ablaufplans und/oder Blockschaubilds angegebenen Funktionen/Handlungen bereitstellen.
Die Ablaufpläne und Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen. In dieser Beziehung kann jeder Block in den Ablaufplänen oder den Blockschaubildern ein Modul, Segment oder einen Codeabschnitt enthalten, das/der eine oder mehrere ausführbare Anweisungen zum Realisieren der angegebenen Logikfunktion(en) aufweist. Es sollte auch beachtet werden, dass bei einigen alternativen Realisierungen die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren angegeben auftreten können.
Zum Beispiel können zwei aufeinander folgend dargestellte Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können in Abhängigkeit von der betreffenden Funktionalität manchmal in der umgekehrten Reihenfolge ausgeführt werden. Es ist ebenfalls zu beachten, dass jeder Block der Blockschaubilder und/oder des Ablaufplans sowie Blockkombinationen in den Blockschaubildern und/oder dem Ablaufplan durch Spezialsysteme auf der Grundlage von Hardware, die die angegebenen Funktionen oder Handlungen ausführen, oder Kombinationen von Spezialhardware und Computeranweisungen realisiert werden können.
Der beanspruchte Gegenstand wird hier mit Bezug auf ein oder mehrere Merkmale oder Ausführungsformen beschrieben. Fachleute werden erkennen und verstehen, dass trotz der Detailliertheit der hier bereitgestellten beispielhaften Ausführungsformen Änderungen und Abwandlungen auf diese Ausführungsformen angewendet werden können, ohne dass der allgemein beabsichtigte Schutzumfang eingeschränkt oder von diesem abgewichen würde. Diese und verschiedene andere Anpassungen und Kombinationen der hier bereitgestellten Ausführungsformen unterliegen dem Schutzumfang des offenbarten Gegenstands, wie er durch die Ansprüche sowie deren sämtliche Äquivalente definiert ist.

Claims

Speicherverwaltungsverfahren in einer virtualisierten Datenverarbeitungsumgebung, bei dem ein Hypervisor mindestens eine virtuelle Maschine „VM” auf einer Hostmaschine realisiert, wobei ein Gastbetriebssystem „BS” auf der VM ausgeführt wird und eine Anwendung, die Speicherverwaltungsfähigkeiten unterstützt, auf dem Gast-BS ausgeführt wird, wobei das Verfahren aufweist: Aufrufen eines ersten, von der Anwendung realisierten Speichermanagers Java-Balloon zwecks Aufhebens der Zuordnung von der Anwendung zugeordnetem Speicher zur Verwendung durch den Hypervisor, als Reaktion auf eine von dem Hypervisor gesendete Anforderung und Aufrufen eines zweiten, auf dem Gastbetriebssystem realisierten Speichermanagers „Gast-Balloon” zwecks Aufhebens der Zuordnung von dem Gast-BS zugeordnetem Speicher, als Reaktion auf eine von dem Hypervisor gesendete Anforderung.
Verfahren nach Anspruch 1, wobei das Aufrufen des ersten Speichermanagers das Beschaffen von Speicher aus der Anwendung zugewiesenem Speicherplatz aufweist.
Verfahren nach Anspruch 2, wobei das Aufrufen des ersten Speichermanagers außerdem das Beibehalten von Verweisen auf den Speicher aufweist, der aus dem der Anwendung zugewiesenen Speicherplatz beschafft wurde.
Verfahren nach Anspruch 3, wobei das Aufrufen des ersten Speichermanagers außerdem das Überwachen aufweist, ob einer ersten, dem ersten Speichermanager Java-Balloon zugehörigen Speicherverwaltungs-Datenstruktur zugeordneter Speicher für das Gast-BS freigegeben werden kann.
Verfahren nach Anspruch 4, das außerdem das Freigeben des der dem ersten Speichermanager Java-Balloon zugehörigen ersten Speicherverwaltungs-Datenstruktur zugeordneten Speichers für das Gast-BS aufweist.
Verfahren nach Anspruch 4, das außerdem das Aufrufen des zweiten Speichermanagers „Gast-Balloon” zum Entziehen von Speicher des Gast-BS aufweist.
Verfahren nach Anspruch 1, wobei das Aufrufen des zweiten Speichermanagers „Gast-Balloon” das Aufrufen des Gast-BS zwecks Zurückgebens von Speicher an die Anwendung aus dem ersten Speichermanager Java-Balloon zugeordnetem Speicher aufweist.
Verfahren nach Anspruch 7, das außerdem das Überwachen aufweist, ob von dem ersten Speichermanager Java-Balloon Speicher für das Gast-BS freigegeben wurde.
Verfahren nach Anspruch 8, wobei, wenn von dem ersten Speichermanager Java-Balloon Speicher für das Gast-BS freigegeben wurde, der freigegebene Speicher aus dem Gast-BS wiederbeschafft wird.
Verfahren nach Anspruch 9, das außerdem aufweist: den ersten Speichermanager Java-Balloon, der die Verweise auf Speicher freigibt, der dem ersten Speichermanager zugehörigen Objekten zugeordnet ist, so dass der zugehörige Speicherplatz von der Anwendung verwendet werden kann.
Speicherverwaltungssystem in einer virtualisierten Datenverarbeitungsumgebung, bei dem ein Hypervisor mindestens eine virtuelle Maschine „VM” auf einer Hostmaschine realisiert, wobei ein Gastbetriebssystem „BS” auf der VM ausgeführt wird und eine Anwendung, die Speicherverwaltungsfähigkeiten unterstützt, auf dem Gast-BS ausgeführt wird, wobei das System aufweist: eine Logikeinheit zum Aufrufen eines ersten, von der Anwendung realisierten Speichermanagers zwecks Aufhebens der Zuordnung von der Anwendung zugeordnetem Speicher zur Verwendung durch den Hypervisor, als Reaktion auf eine von dem Hypervisor gesendete Anforderung und eine Logikeinheit zum Aufrufen eines zweiten Speichermanagers, der auf dem Gastbetriebssystem realisiert ist, zwecks Aufhebens der Zuordnung von dem Gast-BS zugeordnetem Speicher, als Reaktion auf eine von dem Hypervisor gesendete Anforderung.
System nach Anspruch 11, wobei das Aufrufen des ersten Speichermanagers das Beschaffen von Speicher aus der Anwendung zugewiesenem Speicherplatz aufweist.
System nach Anspruch 12, wobei das Aufrufen des ersten Speichermanagers außerdem das Beibehalten von Verweisen auf den Speicher aufweist, der aus dem der Anwendung zugewiesenen Speicherplatz beschafft wurde.
System nach Anspruch 13, wobei das Aufrufen des ersten Speichermanagers außerdem das Überwachen aufweist, ob einer ersten, dem ersten Speichermanager zugehörigen Speicherverwaltungs-Datenstruktur zugeordneter Speicher für das Gast-BS freigegeben werden kann.
System nach Anspruch 14, das außerdem das Freigeben des der dem ersten Speichermanager zugehörigen ersten Speicherverwaltungs-Datenstruktur zugeordneten Speichers für das Gast-BS aufweist.
System nach Anspruch 14, das außerdem das Aufrufen des zweiten Speichermanagers zum Entziehen von Speicher des Gast-BS aufweist.
System nach Anspruch 11, wobei das Aufrufen des zweiten Speichermanagers das Aufrufen des Gast-BS zwecks Zurückgebens von Speicher an die Anwendung aus dem ersten Speichermanager zugeordnetem Speicher aufweist.
System nach Anspruch 17, das außerdem das Überwachen aufweist, ob von dem ersten Speichermanager Java-Balloon Speicher für das Gast-BS freigegeben wurde.
System nach Anspruch 18, wobei, wenn von dem ersten Speichermanager Speicher für das Gast-BS freigegeben wurde, der freigegebene Speicher aus dem Gast-BS wiederbeschafft wird.
System nach Anspruch 19, das außerdem aufweist: den ersten Speichermanager, der die Verweise auf Speicher freigibt, der dem ersten Speichermanager zugehörigen Objekten zugeordnet ist, so dass der zugehörige Speicherplatz von der Anwendung verwendet werden kann.
Computerprogrammprodukt, das ein computerlesbares Speichermedium mit einem computerlesbaren Programm aufweist, wobei ein Speicherverwaltungssystem in einer virtualisierten Datenverarbeitungsumgebung bereitgestellt wird, bei dem ein Hypervisor mindestens eine virtuelle Maschine „VM” auf einer Hostmaschine realisiert, wobei ein Gastbetriebssystem „BS” auf der VM ausgeführt wird und eine Anwendung, die Speicherverwaltungsfähigkeiten unterstützt, auf dem Gast-BS ausgeführt wird, und wobei das computerlesbare Programm, wenn es auf einem Computer ausgeführt wird, den Computer veranlasst zum: Aufrufen eines ersten, von der Anwendung realisierten Speichermanagers zwecks Aufhebens der Zuordnung von der Anwendung zugeordnetem Speicher zur Verwendung durch den Hypervisor, als Reaktion auf eine von dem Hypervisor gesendete Anforderung und Aufrufen eines auf dem Gastsystem realisierten zweiten Speichermanagers, zwecks Aufhebens der Zuordnung von dem Gast-BS zugeordnetem Speicher, als Reaktion auf eine von dem Hypervisor gesendete Anforderung.
Computerprogrammprodukt nach Anspruch 21, wobei das Aufrufen des ersten Speichermanagers das Beschaffen von Speicher aus der Anwendung zugewiesenem Speicherplatz aufweist.
Computerprogrammprodukt nach Anspruch 22, wobei das Aufrufen des ersten Speichermanagers außerdem das Beibehalten von Verweisen auf den Speicher aufweist, der aus dem der Anwendung zugewiesenen Speicherplatz beschafft wurde.
Computerprogrammprodukt nach Anspruch 23, wobei das Aufrufen des ersten Speichermanagers außerdem das Überwachen aufweist, ob einer ersten, dem ersten Speichermanager zugehörigen Speicherverwaltungs-Datenstruktur zugeordneter Speicher für das Gast-BS freigegeben werden kann.
Computerprogrammprodukt nach Anspruch 24, wobei der der ersten, dem ersten Speichermanager zugehörigen Speicherverwaltungs-Datenstruktur zugeordnete Speicher für das Gast-BS freigegeben wird.