DE60130556T2

DE60130556T2 - Virtueller haufen für eine virtuelle maschine

Info

Publication number: DE60130556T2
Application number: DE60130556T
Authority: DE
Inventors: Gregory L. Palo Alto Slaughter; Thomas E. San Jose SAULPAUGH; Bernard A. Menlo Park TRAVERSAT; Michael J. Fremont DUIGOU
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 2000-06-02
Filing date: 2001-05-21
Publication date: 2008-06-12
Anticipated expiration: 2021-05-22
Also published as: EP1297423B1; AU2001264915A1; WO2001095106A2; DE60130556D1; ATE373841T1; WO2001095106A3; US6941410B1; EP1297423A2

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf das Gebiet der virtuellen Maschinen und genauer gesagt auf ein System und ein Verfahren zum Bereitstellen virtueller Heaps für Prozesse, die innerhalb von virtuellen Maschinen ablaufen.
2. Beschreibung des verwandten Standes der Technik
Das Problem des Wanderns eines laufenden Prozesses, beispielsweise eine Anwendung, von einer Maschine zu einer anderen auf einem Netzwerk wird schon seit Jahren behandelt und es gibt umfangreiche Forschungsliteratur zu dem Thema der "Prozeßmigration", jedoch nicht viel Erfolg bei der eigentlichen Lösung dieses schwierigen Problems.
Derzeit gibt es, da die Welt sich in Richtung eines netzwerkzentrierten Modells der Berechnung bzw. des Computerwesens mit einer beispiellosen Verbindungsfähigkeit bewegt, einen wachsenden Bedarf, eine Anwendung (einen Editor, E-Mail, Browser, etc.) auf einem Computer laufen zu lassen, und in der Lage zu sein, später das Weiterlaufen derselben Anmeldung von einer anderen Maschine an einem anderen Ort wieder aufzunehmen. Ein solcher Bedarf kann nur durch eine Wanderung bzw. Migration der Anwendung erfüllt werden. Gleichzeitig sind moderne Betriebssysteme sehr komplex geworden und haben die Tendenz, daß mehrere Anwendungen auf einem sehr leistungsstarken bzw. "dicken" Client (thick client) laufen, und diese Komplexität hat zu einer großen Unzuverlässigkeit geführt. Es ist daher wünschenswert in der Lage zu sein, eine Anwendung von dem Rest des komplizierten Betriebssystems zu trennen und sie irgendwo auf dem Netz aufrechtzuerhalten, wo sie gegenüber dem komplizierten, unzugänglichen bzw. "dicken" Clientsystem geschützt ist. Dieser Bedarf kann ebenso nur durch eine beständige Migration einer Anwendung erfüllt werden.
Java^TM
Die Computerwelt hat derzeit viele Plattformen, darunter Microsoft Windows^®, Apple Macintosh^®, OS/2, UNIX^®, Linux und NetWare^®. Software muß getrennt kompiliert (übersetzt) werden, um auf jeder Plattform zu laufen. Die binäre Datei für eine Anwendung, die auf einer Plattform läuft, kann auf einer Plattform nicht laufen, da die binäre Datei plattformspezifisch ist.
Eine "virtuelle Maschine" kann als eine Betriebsumgebung definiert werden, die oben auf einer oder mehreren anderen Computerplattformen aufsitzt und die Fähigkeit bereitstellt, eine binäre Datei auf der virtuellen Maschine auf der einen oder den mehreren anderen Computerplattformen laufen zu lassen. Es wird also eine Anwendung geschrieben und kompiliert, so daß sie auf der virtuellen Maschine läuft, und sie braucht deshalb nicht getrennt kompiliert werden, um auf der einen oder mehreren anderen Computerplattformen zu laufen.
Die Java-Plattform ist eine Software-Plattform zum Liefern und Laufenlassen von Applets und Anwendungen auf Computersystemnetzwerken. Was die Java-Plattform zu etwas Besonderem macht ist die Tatsache, daß sie oben auf anderen Plattformen aufsitzt und Bytecodes ausführt, die nicht für irgendeine physikalische Maschine spezifisch sind, sondern Maschinenanweisungen für eine virtuelle Maschine sind. Ein Programm, welches in der Java-Sprache geschrieben ist, wird in eine Bytecodedatei kompiliert, die läuft, wo immer die Java-Plattform vorhanden ist, und zwar auf jedem beliebigen zugrundeliegenden Betriebssystem. Mit anderen Worten, dieselbe Datei kann auf irgendeinem Betriebssystem laufen, das auf der Java-Plattform läuft. Die Java-Plattform hat zwei grundlegende Teile, die virtuelle Java-Maschine und die Java-Anwendungsprogrammierschnittstelle (Java-API).
Die Java-Technologien von Sun sind in drei Ausgaben gruppiert: nämlich die Ausgaben Java 2 Micro (J2ME), Standard (J2SE) und Enterprise (J2EE). Jede Ausgabe enthält eine virtuelle Java-Maschine (JVM), die in einen Bereich von Verbrauchereinrichtungen, wie z.B. ein Set-Top, Bildschirmtelefon-, Drahtlos-, Fahrzeug- und digitale Assistenteneinrichtungen paßt. J2ME spricht speziell den Verbraucherraum an, der den Bereich von kleinen Einrichtungen, angefangen von Smartcards und Pagern, bis zu der Set-Top-Box abdeckt, eine Anwendung, die nahezu so leistungsstark ist wie ein Computer. Die Verbrauchereinrichtungen, auf die J2ME abzielt, wie z.B. die Set-Top-Box, Drucker, Kopierer und Mobiltelefon, haben typischerweise weniger Ressourcen und eine starker spezialisierte Funktionalität als ein typischer Netzwerkcomputer. Solche Einrichtungen bzw. Geräte können spezielle Einschränkungen aufweisen, wie z.B. einen begrenzten, kleinen Speicherraum, keine Anzeige oder keine Verbindung zu einem Netzwerk. Die J2ME-API stellt die kleinste Java-API bereit, die eine dieser beschränkten Einrichtungen haben kann und die dennoch laufen kann. Eine unter Java betriebene Anwendung, die für eine spezielle Einrichtung geschrieben wurde, kann auf einer breiten Vielfalt von ähnlichen Einrichtungen laufen. Anwendungen, die mit J2ME geschrieben werden, sind aufwärts skalierbar bzw. aufwärts kompatibel, um mit J2SE und J2EE zu arbeiten.
Der entfernte Methodenaufruf (RMI) von Java
RMI ist eine durch die Java-Programmiersprache ermöglichte Erweiterung von traditionellen Mechanismen für entfernte Prozedurenaufrufe. RMI ermöglicht nicht nur, daß Daten von Objekt zu Objekt durch das Netzwerk weitergeleitet werden, sondern auch vollständige Objekte, einschließlich Code.
Die virtuelle K-Maschine (KVM)
Die virtuelle K-Maschine (KVM) ist eine Java-Laufzeitumgebung, die eine extrem schlanke Implementierung der virtuellen Java-Maschine für die Verwendung in Einrichtungen ist, die eine kleine Speicherbasis haben. Die KVM ist der Kern der Java 2 Mikroausgabe (J2ME). Die KVM ist geeignet für 16/32-bit-RISC/CISC-Mikrocontroller mit einem Gesamtspeicher von nicht mehr als wenigen hundert Kilobyte (KBytes) und mitunter weniger als 128 Kbytes RAM. Dies trifft typischerweise für Einrichtungen mit kleiner Speicherbasis zu, einschließlich digitaler Mobiltelefone, Pager, der etablierten persönlichen Assistenten, der einfachen analogen Z-Top-Boxen und kleiner Bezahlterminals im Einzelhandel.
Anwendungsmigration und Java
Indem eine Anwendung in Java geschrieben wird, ist die Anwendung nicht an eine bestimmte Maschine gebunden, sondern ist stattdessen so geschrieben, daß sie auf einer abstrakten oder "virtuellen" Maschine, der virtuellen Java-Maschine (JVM), läuft. Konsequenterweise ist es möglich, daß die Anwendung auf irgendeiner Maschine auf dem Netzwerk läuft, welche die JVM-Spezifikation implementiert. Dies hilft bei der Prozeßmigration, da frühe Versuche mit diesem Problem aufgrund von Unterschieden, selbst geringen Unterschieden, zwischen den verschiedenen Maschinen auf einem Netzwerk vereitelt wurden, auf welchen eine Anwendung migrieren und laufen sollte. Für sich gesehen kann jedoch auch eine in Java geschriebene Anwendung nicht von einer Maschine auf dem Netz zu einer anderen migrieren, da, nachdem die Anwendung zu laufen begonnen hat, sie nur in dem Heap der JVM läuft, auf welcher sie anfänglich gestartet ist.
Die Javasprache liefert dem Programmierer ein Objektmodell, ein starkes Typensystem, eine automatische Hauptspeicherverwaltung und den gleichzeitigen Lauf über leichte Threads (Stränge). Die Java-Plattform bietet jedoch keinen zufriedenstellenden Weg, diese Eigenschaften über die einzelne Ausführung einer JVM hinaus aufrechtzuerhalten. Stattdessen muß sich der Programmierer ausdrücklich mit dem Speichern des Zustandes einer Anwendung befassen, indem er einen von einer Vielfalt von Dauerhaftigkeitsmechanismen, beispielsweise Dateieingabe/-ausgabe, Objektserienbildung oder Anschlußfähigkeit über relationale Datenbanken verwendet, wobei keiner dieser Ansätze eine vollständige Unterstützung für das komplette Rechnermodell bietet. Dieses Fehlen der Vollständigkeit, auch wenn es nur eine untergeordnete Beeinträchtigung für einfache Anwendungen darstellt, wird ein ernsthaftes Problem, wenn die Komplexität einer Anwendung zunimmt.
Orthogonale Persistenz für Java
Orthogonale Persistenz (Dauerhaftigkeit) für die Java-Plattform (OPJ) befaßt sich mit einigen der Einschränkungen der Anwendungsmigration bei Java, ohne daß Änderungen in der Quellsprache erfolgen, und mit geringen Modifizierungen in der Spezifizierung des Lebenszyklus der virtuellen Java-Maschine. Im Ergebnis erweitert orthogonale Persistenz die automatische Speicherverwaltung der Java-Plattform, um einen stabilen Speicher einzubeziehen.
OPJ erlaubt, daß eine laufende Java-Anwendung ohne Änderung an der Anwendung oder an Java dauerhaft bestehen bleibt (also orthogonal ist). Dies wird erreicht durch Verbesserungen an der JVM, die einen persistenten bzw. dauerhaften Heap implementieren, der parallel zu dem Heap ist, in welchem der Java-Code läuft. Es ist möglich, eine laufende Anwendung auszusetzen und ein Fixpunktergebnis in dem persistenten Heap zu haben, das später auf derselben JVM wieder aktiviert werden kann. Das Wandern bzw. Migrieren zu einer anderen JVM oder einer anderen Maschine wird jedoch nicht unterstützt.
Eine weitere Einschränkung des persistenten Heap und der Fixpunkterstellung, wie sie in der OPJ implementiert ist, liegt dann, daß irgendwelche Teile eines Prozesses, die von einem externen Zustand abhängig und nicht vorübergehend sind, ungültig sein können, wenn der Code erneut läuft, da der aktuelle externe Zustand sich möglicherweise verändert hat. Ein Beispiel eines externen Zustandes ist ein Anschluß bzw. ein Kanal (Socket) für eine Netzwerkverbindung.
Eine weitere Einschränkung des persistenten Heap und der Fixpunkterstellung, wie sie in OPJ implementiert sind, liegt darin, daß sie einen großen persistenten Heap für sämtlichen Java-Code unterstützt, der auf dem System läuft, was es schwierig macht, eine spezielle Anwendung abzutrennen, damit diese auf einen anderen Knoten migriert. Der persistente Heap kann Java-System-Objekte und Java-Anwendungs-Objekte umfassen. Java-System-Objekte sind diejenigen Java-Objekte, die an die Plattform gebunden sind (Maschine und Betriebssystem), auf welcher die JVM mit der Java-Ursprungsschnittstelle (native Java-Schnittstelle – JNI) läuft. Java-System-Objekte können native Methoden für die Plattform umfassen, auf welcher die JVM ausgeführt wird. Die Java-Anwendungsobjekte für die spezielle Anwendung müßten von den Java-Anwendungsobjekten aus irgendeinem anderen laufenden Prozeß und von den Java-System-Objekten getrennt werden.
Eine weitere Einschränkung des OPJ-Modells liegt dann, daß es zwei getrennte Abfallsammler erfordert, einen für den Heap "innerhalb des Speichers" und einen für den persistenten Heap.
JVM-Abtrennmodelle
In einem System, welches Anwendungsmigration bereitstellt, wäre es wünschenswert, eine Anwendung abzutrennen, so daß sie allein in einem Heap läuft (und dauerhaft in einem persistenten Heap gehalten wird). Eine Art dies zu tun liegt darin, für jede Anwendung eine getrennte JVM auf der Maschine zu starten. Auch wenn dieser Ansatz einfach ist, ist er möglicherweise nicht praktikabel. Zum einen verbraucht diese Lösung viele Systemressourcen. Andere Ansätze für die Anwendungsabtrennung sind hierarchisch, wobei man eine "reale" JVM und zahlreiche "virtuelle" JVMs hat, die obendrauf vervielfacht sind. Es wäre wünschenswert, ein Abtrennungsmodell der virtuellen Maschine bereitzustellen, das Anwendungen in diskrete dauerhafte Speicher abtrennt, das Laufen von Anwendungen eine nach der anderen in einem innerhalb des Speichers liegenden Heap erlaubt und dieses durchführt, ohne daß es erforderlich ist, mehrere Kopien (real oder virtuell) der JVM laufen zu lassen.
Die europäische Patentanmeldung EP-A-0,483,525 beschreibt eine Speicherverwaltungstechnik, durch welche weniger häufig verwendete Seiten auf eine Speicherbank mit geringem Energieverbrauch abgebildet werden, um Energie bzw. Leistung einzusparen. Eine erste Speicherbank weist einen normalen RAM auf. Eine zweite Speicherbank weist einen weniger leistungsstarken bzw. weniger Energie verbrauchenden RAM auf. Häufig verwendete virtuelle Sei ten werden auf die erste Speicherbank abgebildet bzw. dort abgespeichert, während weniger häufig verwendete virtuelle Seiten auf die zweite Speicherbank abgebildet bzw. dort gespeichert werden.
Die europäische Patentanmeldung EP-A-0,330,087 beschreibt ein erweitertes Speichersystem das einen Datenübertragungspfad umfaßt, der zwischen einem Arbeitsspeicher, welcher zwischen einem Hauptspeicher und einem Pufferspeicher liegt, und einem erweiterten Speicher vorgesehen ist. Der Arbeitsspeicher wird in einem sogenannten Einspeichermodus gesteuert bzw. kontrolliert und wird mit einem gültigen Flag versehen, das die Gültigkeit einer Kopie von Daten anzeigt.
ZUSAMMENFASSUNG DER ERFINDUNG
Aspekte der Erfindung sind in den anhängenden Ansprüchen dargelegt. Die oben skizzierten Probleme können zum großen Teil durch eine Ausführungsform der Erfindung gelöst werden, wobei diese Ausführungsform ein System und ein Verfahren zur Migration von dauerhaften Anwendungen bereitstellen kann, das die Abtrennung einer Anwendung und ein Verfahren zum Aufrechterhalten der Eigenschaften eines Prozesses über die Einzelausführung einer virtuellen Maschine, wie z.B. einer virtuellen Java-Maschine (JVS), hinaus bereitstellt, während es den externen Zustand des Prozesses bewahrt.
In einer Ausführungsform kann eine Anwendung auf einem System von anderen Anwendungen und von Systemcode und Daten abgetrennt werden und ist damit getrennt von den anderen Anwendungen wanderungsfähig. In einer Ausführungsform können eine oder mehrere Anwendungen auf einem System jeweils einen innerhalb eines Speichers liegenden Heap haben, der als ein "physikalischer" Speicher dient, der für die aktuelle Ausführung der Anwendung verwendet wird, einen virtuellen Heap, der den gesamten Heap der Anwendung, einschließlich zumindest eines Teiles der Laufzeitumgebung, und einen dauerhaften Heap oder Speicher haben, wobei der virtuelle Heap mit Fixpunkten versehen werden kann. In einer Ausführungsform können der virtuelle Heap und der dauerhafte Heap in einem Speicher kombiniert werden (der virtuelle Heap kann als der persistente Heap dienen). Alternativ kann der virtuelle Heap durch Fixpunkte zu einem getrennten, zu unterscheidenden dauerhaften Heap gemacht werden. Die Kombination des Heaps im Speicher, des virtuellen Heaps und des dauerhaften Speichers kann als der "virtuelle persistente Heap" bezeichnet werden.
Ein Heap kann Code und Daten für die Verwendung durch eine Anwendung enthalten. In objektorientierten Programmiersprachen, wie z.B. Java, kann zumindest ein Teil des Codes und der Daten in dem Heap für die Anwendung in Objekten gekapselt sein. Objekte können als Strukturen definiert werden, die Instanz einer bestimmten Klasse oder Teilklasse von Objekten sind. Objekte können Instanzen der Methoden oder Prozeduren der Klasse (Code) und/oder Daten, die sich auf das Objekt beziehen, enthalten. Ein Objekt ist das, was im eigentlichen Sinne in einem objektorientierten Programm auf dem Computer "läuft".
Ein Heap kann auch Strukturen zum Verwalten des Code und der Daten der Anwendung in dem Heap enthalten. Beispielsweise kann ein Heap in Sektionen aufgeteilt sein, z.B. Seiten oder Cachezeilen. Die Sektionen des Heap können für einige Heap-Verarbeitungsfunktionen, wie z.B. die Abfallsammlung, in Sätze von zwei oder mehr Abschnitten gruppiert sein. Abschnitte des Heap können Strukturen zum Verwalten von Code und Daten (Objekten) in dem Abschnitt umfassen. Beispielsweise können eine oder mehrere Strukturen zum Verfolgen interner und externer Aufrufe von Objekten in einer Sektion in den Speichersektionen aufbewahrt werden. Ein interner Aufruf eines Objektes kann als ein Aufruf an ein Objekt von einem anderen Objekt in demselben Abschnitt des Heap definiert werden. Ein externer Aufruf kann als ein Aufruf eines Objektes von einem anderen Objekt in einer anderen Sektion des Heap definiert werden.
In einer Ausführungsform kann die Anwendung eine oder mehrere Überlassungen (Leases) für lokale und/oder entfernte Dienste außerhalb der Anwendung bereitstellen. In einer Ausführungsform kann eine Anwendung eine oder mehrere Überlassungen von Systemcode bereitstellen, die der Anwendung Zugriff auf Ressourcen gewährt, die außerhalb der Anwendung liegen, wie z.B. auf Systemressourcen. Systemcode für das Zugreifen auf eine externe Ressource kann als ein Systemdienst bezeichnet werden. Eine Überlassung von Systemcode für das Zugreifen auf eine externe Ressource kann als ein überlassener Systemdienst bezeichnet werden. Beispielsweise kann eine Anwendung Überlassungen von Systemdiensten bereitstellen, die der Anwendung Zugriff auf System-Treiber für das Zugreifen auf Kommunikationsanschlüsse in dem System gewährt.
In einem virtuellen persistenten Heap kann der gesamte Heap persistent gemacht werden. Der virtuelle persistente Heap kann die Fixpunkterstellung des Zustandes der Berechnung der virtuellen Maschine in einem dauerhaften Speicher, wie z.B. eine Festplatte oder eine Flasheinrichtung, für die spätere Wiederaufnahme der Berechnung an dem Ort des Fixpunktes ermöglichen. Der virtuelle persistente Heap ermöglicht vorzugsweise auch die Migration der Berechnungszustände der virtuellen Maschine von einer Maschine zu einer anderen. Sowohl die Daten als auch der Rechnungszustand können übertragen werden. Eine Ausführungsform kann auch die Aussetzung und Wiederaufnahme einer Anwendung vorsehen, wie z. B. beim erneuten Starten einer Einrichtung bzw. eines Gerätes nach einem absichtlichen oder unabsichtlichen Abschalten des Gerätes.
In einer Ausführungsform kann der virtuelle Heap das Laufen eines Prozesses auf einem physikalischen Heap ermöglichen, der kleiner ist, als es ansonsten erforderlich wäre. Zum Beispiel kann der virtuelle Heap eine Größenordnung größer sein als der physikalische, speicherinterne Heap. In einer Ausführungsform kann der virtuelle Heap auf einem nichtflüchtigen Speicher gehalten werden, der außerhalb des Gerätes liegt, auf welchem die virtuelle Maschine läuft, und Teile des Heap für den aktuellen Ausführungszustand des Prozesses können in einem "physikalischen" Heap cachegespeichert und ausgelesen werden, der in dem lokalen Speicher auf dem Gerät liegt. Beispielsweise kann das Gerät sich mit einem Server im Internet verbinden, und der Server kann nichtflüchtigen Speicherraum für den virtuellen Heap bereitstellen. In einer anderen
Ausführungsform kann der externe Speicher für den virtuellen Heap auf einem nichtflüchtigen Speicher liegen, der an dem Gerät angebracht ist, beispielsweise einer Flashkarte oder einem Festplattenlaufwerk.
Aufgrund der Persistenz bzw. Dauerhaftigkeit kann eine Anwendung mit Fixpunkten versehen und auf einer virtuellen Maschine ausgesetzt bzw. unterbrochen werden, und eine zweite Anwendung kann dann die Ausführung auf der virtuellen Maschine beginnen, ohne daß der Prozeß der virtuellen Maschine beendet wird. Dies vermeidet die Zusatzlast des Startens einer neuen virtuellen Maschine für eine neue Anwendung. Beispielsweise kann eine virtuelle Maschine auf einem System gestartet werden, wenn man eine erste Anwendung laufen lassen muß. Wenn eine zweite Anwendung gestartet wird, braucht der Webbrowser keine zweite virtuelle Maschine zu starten, um die zweite Anwendung laufen zu lassen, wie dies im Stand der Technik geschieht, sondern kann statt dessen einen Fixpunkt für die erste Anwendung erstellen und diese aussetzen und kann dann die zweite Anwendung auf derselben virtuellen Maschine laufen lassen, auf der auch die erste Anwendung lief. Für die zweite Anwendung kann an irgendeinem Punkt (ebenfalls) ein Fixpunkt erstellt werden, und sie kann dann ausgesetzt werden, und die erste Anwendung kann ihre Ausführung bei dem letzten Fixpunktzustand, der vor ihrer Aussetzung lag, wieder aufnehmen. In einem anderen Beispiel kann ein Webbrowser eine virtuelle Maschine starten, um eine erste Anwendung laufen zu lassen. Der Webbrowser kann die virtuelle Maschine aktiv halten, nachdem die erste Anwendung abgeschlossen ist und kann sie später verwenden, um eine zweite Anwendung laufen zu lassen. Im Stand der Technik hätte das Beenden einer Anwendung bewirkt, daß auch die virtuelle Maschine, auf welcher diese lief, ihre Ausführung ebenfalls beenden würde, was erfordert, daß für jede Anwendung eine neue virtuelle Maschine gestartet wird.
Der virtuelle persistente Heap kann das Aufbewahren des gesamten Zustandes des Heap der virtuellen Maschine für eine mögliche spätere Wiederaufnahme der Berechnung, an dem Punkt, an welchem die Speicherung bzw. Aufbewahrung durchgeführt wurde, ermöglichen, und kann die Migration der Berechnung zu einem anderen System ermöglichen. In einer Ausführungsform kann der gespeicherte bzw. aufbewahrte Zustand des Heap der virtuellen Maschine auch die Fähigkeit bereitstellen, die virtuelle Maschine nach einem Systemzusammenbruch oder Abschalten an einem zuvor gespeicherten, persistenten bzw. dauerhaften Zustand erneut zu starten. Dieses Dauerhaftigkeitsmerkmal kann für kleinere Verbraucher und Anwendungsgeräte, welche javafähige Geräte einschließen, zweckmäßig sein, wie z. B. für Mobiltelefone und Personal Digital Assistants (PDAs), da diese Geräte häufig abgeschaltet und erneut gestartet werden können. Der virtuelle persistente Heap kann den gesamten Adreßraum des Heap der virtuellen Maschine umfassen, den eine Anwendung verwendet.
Ausführungsformen des virtuellen persistenten Heap können zumindest entweder ein Cacheverfahren und/oder ein Datenbankspeicherverfahren und/oder ein Abfallsammelverfahren umfassen, wie es nachstehend beschrieben wird.
Ein Cacheverfahren für den virtuellen persistenten Heap
Ein Merkmal des virtuellen persistenten Heap ist das Verfahren, welches verwendet wird, um Teile des virtuellen persistenten Heap in dem physikalischen Heap cachezuspeichern. In einer Ausführungsform kann der virtuelle persistente Heap einen Cachemechanismus bzw. Cachespeichermechanismus umfassen, der bei kleinen Verbraucher- und Anwendungsgeräten wirksam ist, die typischerweise einen kleinen Speicherumfang haben und die möglicherweise Flashgeräte bzw. Flasheinrichtungen als dauerhaften Speicher verwenden. Die Cachespeicher-Strategie kann einen reduzierten Umfang an Cachespeicherung vorsehen und kann dabei helfen, die Lokalität von Elementen des virtuellen persistenten Heap zu verbessern, die in dem physikalischen Heap cachegespeichert sind, wodurch die Zusatzlast durch die Cachespeicherung minimal gemacht wird.
Eine Ausführungsform umfaßt einen Cachemechanismus, bei welchem der virtuelle persistente Heap in Cachezeilen aufgeteilt ist. Eine Cachezeile ist die kleinste Menge an virtuellem persistenten Heapraum, die gleichzeitig geladen oder ausgespült werden kann. Vorgänge der Cachespeicherung und des Auslesens aus dem Cachespeicher werden verwendet, um Cachezeilen in den Heap zu laden oder um verunreinigte Cachezeilen in den Speicher (Hauptspeicher) auszuspülen. Um den Heapabfall zu reduzieren, kann die Lokalität in einer Cachezeile verbessert werden durch Verwendung Objektcachespeicher-Schulen bzw. "Kinderstuben" und einen nach Generationen organisierten Abfallsammler.
Datenbankspeichermethode für einen virtuellen persistenten Heap
In einer Ausführungsform können eine Datenbankspeichermethode und eine Anwendungsprogrammierschnittstelle (API) für den virtuellen persistenten Heap vorgesehen sein. Die Datenbankspeichermethode kann einen Mechanismus bereitstellen, um Teile des virtuellen, persistenten Heap in einem Cache in dem speicherinternen physikalischen Heap für die virtuelle Maschine aufzunehmen. Der virtuelle Heap kann in einem dauerhaften Speicher gespeichert werden. In einer Ausführungsform können also die Datenbankspeichermethode und API so bereitgestellt werden, daß sie den virtuellen, persistenten Heap in dem Speicher verwalten. Die Speicher-API kann eine Unteilbarkeit der Speichertransaktion gewährleisten, um die Konsistenz der in der Datenbank gespeicherten Information im wesentlichen zu garantieren.
Die Datenbankspeicher-API kann mehrere Verfahren vorsehen, um den virtuellen persistenten Heap in dem Speicher zu verwalten. Diese Verfahren bzw. Methoden können die folgenden umfassen, ohne darauf beschränkt zu sein: Öffnen des Speichers, Schließen des Speichers, unteilbare Lesetransaktion (Lesen eines Satzes von Cachezeilen), unteilbare Schreibtransaktion (Schreiben eines Satzes von Cachezeilen) und unteilbare Löschtransaktion (Löschen eines Satzes von Cachezeilen).
Abfallsammlungsmethode für einen virtuellen persistenten Heap
Eine Abfallsammelmethode kann für den virtuellen persistenten Heap vorgesehen sein. In einer Ausführungsform kann die Abfallsammelmethode bei kleinen Verbraucher- und Anwendungsgeräten, beispielsweise Java-fähigen Geräten, verwendet werden, die möglicherweise nur einen kleinen Speicherumfang haben und welche möglicherweise Flash-Einrichtungen als dauerhaften Speicher verwenden. In einer Ausführungsform wird die Abfallsammelmethode implementiert, um eine gute Leistungsfähigkeit bereitzustellen, wobei nur ein Teil des virtuellen persistenten Heap in dem physikalischen Heap Cache-zwischengespeichert wird. Der virtuelle persistente Heap kann einen einzelnen, virtuellen Heap-Adreßraum sowohl für den Speicherheap als auch für den speicherinternen Heap verwenden. In einer Ausführungsform kann man einen einzelnen Abfallsammler auf dem Adreßraum des virtuellen Heap laufen lassen.
In einer Ausführungsform kann die Abfallsammelmethode am Grund des Heap beginnen und Objekte mit Flags versehen, die aufgerufen werden (d.h. die in dem Heap behalten werden müssen). Dann können Objekte, die nicht mit Flags versehen sind, aus dem Heap entfernt werden. Alternativ kann die Abfallsammelmethode Objekte mit Flags versehen, die nicht aufgerufen werden, und kann dann die mit Flag versehenen Objekte entfernen. Die Abfallsammlung kann bewirken, daß der Heap zerstückelt wird, so daß ein großes Objekt möglicherweise nicht in den verfügbaren freien Raum paßt. Die Abfallsammelmethode kann daher eine Kompaktierungsphase umfassen, um die Zerstückelung zu vermindern oder im wesentlichen zu beseitigen und um die Objektanordnung zu verbessern.
Kleine Anwendungs- und Verbrauchergeräte können Flash-Einrichtungen für eine nicht flüchtige Speicherung verwenden. Flash-Einrichtungen haben typischerweise spezielle Eigenschaften, wie z.B. große I/O-Blöcke zum Schreiben (beispielsweise 128 Kbytes) und destruktive Schreibvorgänge. In einer Ausführungsform kann die Anzahl von Schreibvorgängen, die durch den Abfallsammler mit der Flash-Einrichtung durchgeführt wird, minimal gemacht werden, um die Lebensdauer der Flash-Einrichtung zu erhöhen. Der Abfallsammler für den virtuellen persistenten Heap kann implementiert werden unter Verwendung von Arbeitssätzen und/oder Objekt "schulen" (bzw. „Objektkinderstuben") für kurzlebige Objekte.
KURZE BESCHREIBUNG DER FIGUREN
Andere Ziele und Vorteile der Erfindung werden offensichtlich beim Lesen der folgenden genauen Beschreibung und unter Bezug auf die beigefügten Zeichnungen, von denen:
1a ein Blockdiagramm ist, welches eine Einrichtung mit einem virtuellen, persistenten Heap und einem persistenten Speicherraum veranschaulicht, der auf einer Einrichtung gemäß einer Ausführungsform der Erfindung lokalisiert ist,
1b ein Blockdiagramm ist, welches eine Einrichtung mit einem virtuellen persistenten Heap und einem dauerhaften Speicherraum veranschaulicht, die gemäß einer Ausführungsform der Erfindung außerhalb der Einrichtung lokalisiert sind,
1c ein Blockdiagramm ist, welches eine Einrichtung mit einem virtuellen persistenten Heap auf der Einrichtung und einem dauerhaften Speicherraum zeigt, der gemäß einer Ausführungsform außerhalb der Einrichtung angeordnet ist,
1d ein Blockdiagramm ist, welches ein Clientgerät, einen Proxyserver und einen Server mit einem persistenten Speicherraum gemäß einer Ausführungsform der Erfindung veranschaulicht,
1e ein Blockdiagramm ist, welches einen virtuellen Heap und Überlassungen von lokalen und entfernt gelegenen Ressourcen gemäß einer Ausführungsform der Erfindung zeigt,
1f ein Blockdiagramm ist, welches virtuelle Heaps einer Anwendung und Überlassungen von Systemressourcen gemäß einer Ausführungsform der Erfindung zeigt,
2 ein Blockdiagramm ist, welches die Architektur eines virtuellen persistenten Heap gemäß einer Ausführungsform der Erfindung zeigt,
3 ein Zustandsdiagramm ist, welches die Zustände einer Seite in einem virtuellen persistenten Heap gemäß einer Ausführungsform der Erfindung zeigt,
4 ein Flußdiagramm ist, welches eine Berechnungsmethode für die speicherinternen Heap-Seitenadressen gemäß einer Ausführungsform der Erfindung zeigt,
5a ein Blockdiagramm ist, welches einen Migrationsprozeß einer Anwendung mit einem gespeicherten Zustand von einem ersten Prozeß, der aus einem dauerhaften Speicher an einen zweiten Prozeß gesendet wird, gemäß einer Ausführungsform der Erfindung zeigt,
5b ein Blockdiagramm ist, welches den Migrationsprozeß einer Anwendung in einem persistenten Speicher für jeden Prozeß gemäß einer Ausführungsform der Erfindung zeigt,
6 ein Flußdiagramm ist, welches eine Methode für die Migration einer Anwendung gemäß einer Ausführungsform der Erfindung zeigt,
7 ein Blockdiagramm ist, welches eine Architektur eines virtuellen persistenten Heap unter Verwendung von Cachezeilen gemäß einer Ausführungsform der Erfindung zeigt,
8 ein Flußdiagramm ist, welches eine Berechnungsmethode für die Adressen der Cachezeilen des speicherinternen Heap gemäß einer Ausführungsform der Erfindung zeigt,
9 ein Blockdiagramm ist, welches eine Einrichtung mit einem virtuellen Heap, eine Objektschule und einen Abfallsammler gemäß einer Ausführungsform der Erfindung zeigt,
10a ein Flußdiagramm ist, welches die Abfallsammlung in einem virtuellen Heap gemäß einer Ausführungsform der Erfindung zeigt,
10b ein Flußdiagramm ist, welches die Arbeit eines Schulbereichs in einem virtuellen Heap gemäß einer Ausführungsform zeigt,
10c ein Flußdiagramm ist, welches die Abfallsammlung zeigt, die mit einem oder mehreren Bereichen eines Heap gemäß einer Ausführungsform der Erfindung durchgeführt wird,
11a ein Flußdiagramm ist, welches für einen Prozeß eine unteilbare Lesetransaktion aus einem persistenten Speicher zeigt,
11b ein Flußdiagramm ist, welches für eine Prozeß eine unteilbare Schreibaktion in einen persistenten Speicher zeigt, und
11c ein Flußdiagramm ist, welches für einen Prozeß eine unteilbare Löschtransaktion in einem persistenten Speicher zeigt.
Bezugszeichen für Gegenstände in den Figuren können in mehr als einer Figur wiederholt werden, um Objekte zu kennzeichnen, die in den Figuren weitgehend gleich oder ähnlich sind.
Während die Erfindung für verschiedene Modifikationen und alternative Formen geeignet ist, werden spezielle Ausführungsformen in den Figuren beispielhaft dargestellt und werden hier im einzelnen beschrieben. Es versteht sich jedoch, daß die Zeichnungen und die genaue Beschreibung hierzu nicht die Erfindung auf die speziell offenbarte Form beschränken sollen.
GENAUE BESCHREIBUNG VERSCHIEDENER AUSFÜHRUNGSFORMEN
1a – Eine Einrichtung mit einem virtuellen persistenten Heap auf der Einrichtung
1a zeigt eine Ausführungsform einer Einrichtung bzw. eines Gerätes 140 mit einer virtuellen Maschine 101 und einem virtuellen Heap mit Dauerhaftigkeit (Persistenz), der als ein virtueller persistenter Heap bezeichnet wird. In einem virtuellen persistenten Heap kann der gesamte Heap persistent gemacht werden. Der virtuelle persistente Heap kann das Setzen von Fixpunkten (Programmhaltepunkten) für den Berechnungszustand der virtuellen Maschine in einen persistenten Speicher, wie z.B. eine Festplatte oder eine Flash-Einrichtung, für die spätere Wiederaufnahme der Berechnung an der Stelle des Fixpunktes ermöglichen. Der virtuelle persistente Heap kann auch die Migration der Berechnungszustände der virtuellen Maschine von einer Maschine zu einer anderen ermöglichen. Sowohl Daten als auch der Berechnungszustand können migrieren bzw. versetzt werden. Eine Ausführungsform kann auch die Aussetzung und Wiederaufnahme einer Anwendung bereitstellen, wie z.B. beim erneuten Starten eines Gerätes nach einem absichtlichen oder unabsichtlichen Abschalten des Gerätes.
In 1a umfaßt das Gerät bzw. die Einrichtung 140 einen Client 101 und einen Speicher 115. Das Clientgerät 140 kann eine Computerplattform mit einem Betriebssystem, wie z.B. ein PC oder Laptopcomputer sein, auf welchem ein Betriebssystem, wie z.B. Windows Microsoft 9x/NT, läuft, oder ein Verbraucher- oder Anwendungsgerät, beispielsweise ein Mobiltelefon oder ein PDA. Das Kleingerät kann einen Dienstproviderclient, beispielsweise einen Jini-Client (nicht dargestellt), umfassen, um Dienste auf entfernten Servern auf einem Netzwerk zu finden und zu mieten. Der Client 101 kann eine virtuelle Maschine wie z.B. eine JVM oder eine KVM sein. Der Client 101 kann verwendet werden, um Anwendungen laufen zu lassen, beispielsweise Java-Anwendungen. Eine oder mehrere Anwendungen können auf dem Client 101 laufen, wobei typischerweise eine Anwendung ausgeführt wird und eine oder mehrere Anwendungen ausgesetzt sind. Die Anwendung 104 ist als eine aktuell ablaufende Anwendung dargestellt.
Der Speicher 115 kann in das Kleingerät 140 integriert oder direkt an diesem angebracht sein. Der Speicher 115 kann ein flüchtiger Speicher, wie z.B. direkte Inline-Speichermodule (DIMMs) oder auch ein nicht-flüchtiges Speichergerät sein, wie z.B. ein Flash-Speicher, eine Festplatte oder eine herausnehmbare Festplatte wie z.B. eine Diskette. Diese Ausführungsform kann dauerhaften Speicherraum 120 in dem Speicher 115 verwenden, um den virtuellen Heap 110 für die Anwendung 104 zu speichern. Der dauerhafte Speicherraum 120 kann auch virtuelle Heaps (nicht dargestellt) für eine oder mehrere andere ausgesetzte Anwendungen umfassen.
Das Gerät 140 kann ein Betriebssystem aufweisen, das in der Lage ist, die Software auszuführen, um eine virtuelle Maschine, wie z.B. eine JVM oder eine KVM zu ermöglichen. Das Betriebssystem kann einen Verwalter des virtuellen Speichers (VMM) für die Verwaltung des virtuellen Speichers auf dem Gerät 140 umfassen. Der VMM kann Anwendungen ermöglichen, wie z.B. eine virtuelle Maschine, die auf dem Gerät 140 läuft und die so erscheint, als habe sie mehr physikalischen Speicher als tatsächlich auf dem System vorhanden ist, indem virtueller Speicher freigegeben wird. Die VMM kann Speicherraum, wie z.B. ein Festplattenlaufwerk, verwenden, um einen Austauschbereich einzurichten. Abschnitte des Speichers können in einem Cachebereich in dem physikalischen Speicher für einen schnelleren Zugriff durch eine auf dem Gerät 140 laufende Anwendung aufgenommen werden. Abschnitte des Speichers können in den Austauschbereich auf dem Speicher ausgespült werden, wenn sie durch eine Anwendung nicht aktiv gebraucht werden oder um in dem physikalischen Speicher für andere Abschnitte von Speicher Platz zu schaffen, die unmittelbarer für einen direkten Zugriff durch eine Anwendung angefordert werden können. Die Abschnitte des Speichers in dem virtuellen Speicher auf dem Gerät können für die Anwendung als der Heap bezeichnet werden. Demnach kann eine virtuelle Maschine auf einem Gerät 140 auf einem Heap in dem virtuellen Speicher des Gerätes laufen.
Die virtuelle Maschine kann in einem Teil des Speicherraumes ausgeführt werden, der durch das Betriebssystem auf dem Gerät 140 verwaltet wird. In einer Ausführungsform kann der Speicherraum ein virtueller Speicherraum sein, der durch eine VMM für das Betriebssystem verwaltet wird. Die virtuelle Maschine kann Speicherraum einer virtuellen Maschine für die Verwendung durch Prozesse aufweisen, die auf der virtuellen Maschine ablaufen. In dem hier verwendeten Sinne bezieht sich "Prozeß" auf Anwendungen, Applets, Programme, Aufgaben, Teilprozesse, Threads und Treiber, ist jedoch nicht notwendigerweise hierauf beschränkt. Der Speicherraum der virtuellen Maschine kann durch einen virtuellen Speicherverwalter der virtuellen Maschine (VM VMM) verwaltet werden, wie hier beschrieben wird. Der VM VMM kann zulassen, daß Prozesse, die auf der virtuellen Maschine ablaufen, einen virtuellen Heap verwenden, wie es hier beschrieben wurde, und kann auch eine Dauerhaftigkeit für den virtuellen Heap bereitstellen. Der virtuelle Heap kann einen speicherinternen Heap umfassen, wie schon beschrieben wurde, der in dem Speicherraum der virtuellen Maschine resident sein kann. Der virtuelle Heap kann auch einen Speicherheap umfassen, wie es hier beschrieben wurde. In einer Ausführungsform kann der Speicherheap in dem Speicherraum der virtuellen Maschine resident sein. In einer anderen Ausführungsform kann der Speicherheap in einem Speicher resident sein, der außerhalb der virtuellen Maschine liegt, wie z.B. auf einer Speichereinrichtung, die direkt an dem Gerät 140 oder über das Internet daran angebracht ist, jedoch unter Verwendung des VM VMM zugänglich ist. Der gesamte Speicherraum, einschließlich des Speicherraums der virtuellen Maschine und des Speicherheap kann als der virtuelle Speicherraum der virtuellen Maschine bezeichnet werden.
Der VM VMM, wie er hier beschrieben wird, ermöglicht, daß Anwendungen auf einer virtuellen Maschine auf dem Gerät 140 ablaufen, die ansonsten zuviel Speicherraum der virtuellen Maschine erfordern und demnach nicht ablaufen würden, indem ein virtueller Speicherraum einer virtuellen Maschine und ein virtueller Heap für die Anwendung bereitgestellt wird. Der VM VMM und der virtuelle Heap, wie sie hier beschrieben werden, können auch ermöglichen, daß mehrere Anwendungen auf einer virtuellen Maschine laufen, indem sie einen Speicherheap für jede Anwendung bereitstellen und es zulassen, daß eine Anwendung ausgesetzt wird, indem der speicherinterne Heap in den Speicherheap gespült wird, und daß eine zweite Anwendung wiederaufgenommen wird, indem ihr speicherinterner Heap aus dem Speicherheap in den Speicherraum der virtuellen Maschine geladen wird.
In dem hier verwendeten Sinne kann die Definition eines Heap einen Bereich eines Com puterhauptspeichers (Memory) umfassen, den ein Prozeß möglicherweise verwendet, um Daten in unterschiedlicher Menge zu speichern, die noch nicht bekannt ist, bis das Programm läuft. Ein Heap kann für Daten reserviert werden, die während der Laufzeit erzeugt werden, d.h. wenn ein Programm ausgeführt wird. Ein Heap kann auch Teile eines Codes für den Prozeß umfassen. In einer Ausführungsform kann der Prozeß ein Java-Prozeß sein und der Code kann in Java-Klassen vorliegen. Beispielsweise kann ein Programm unterschiedliche Mengen an Eingaben von einem oder mehreren Benutzern für die Verarbeitung annehmen und dann die Verarbeitung mit allen eingegebenen Daten auf einmal ausführen. Der Heap kann für den zu verwendenden Prozeß vorab zugeordnet sein. Der Prozeß verwaltet seinen zugewiesenen Heap durch Anfordern eines Teiles des Heap, wenn er benötigt wird, Zurückliefern der Teile, wenn sie nicht mehr benötigt werden und Durchführung von gelegentlicher "Abfallsammlung", was nicht mehr verwendete Teile des Heap wieder verfügbar macht, und er kann auch den verfügbaren Raum in dem Heap neu organisieren, um die Zerstückelung des Speichers minimal zu machen. In einer Ausführungsform können Java-Klassen, einschließlich Java-Klassen, welche Code für den Prozeß enthalten, von Abfall bereinigt werden, um Klassen (und damit Prozeßcode) zu entfernen, die nicht mehr in Gebrauch sind. Ein Heap kann in Blöcke, Sektoren, Seiten, Cachezeilen oder irgendeine andere Aufteilung von Speicher aufgeteilt sein, welche die Erfordernisse der Heap-Verwaltungsmethode erfüllt.
Ein "Stapel" (stack) kann als ein Bereich von Speicher definiert werden, der für Daten verwendet werden kann, deren Größe festgelegt werden kann, wenn das Programm kompiliert ist. Ein Stapel kann im wesentlichen ähnlich wie ein Heap verwaltet werden, mit Ausnahme der Tatsache, daß Teile des Stapels nur in einer bestimmten Reihenfolge aus dem Speicher herausgenommen werden können und auf dieselbe Weise zurückgegeben werden müssen.
Das Clientgerät 140 kann auch flüchtigen Speicher zum Laden und Laufenlassen des Client 101 umfassen. Der Client 101 kann dann Anwendungen in seinen Speicherraum laden und laufen lassen. Der speicherinterne Heap 108 kann in dem Speicherraum des Client 101 oder alternativ in einem außerhalb des Speicherraums des Client 101 liegenden Speicher aufbewahrt werden. Der speicherinterne Heap 108 kann einen Teil eines virtuellen Heap 110 umfassen, der für die Verwendung durch die Anwendung 104 aktuell in einem Cache aufgenommen ist.
Der speicherinterne Heap 108 und der virtuelle Heap 110 können in eine oder mehrere Abschnitte aufgeteilt sein. Die Abschnitte können Sektoren, Seiten, Cachezeilen oder irgendeine andere Aufteilung von Speicherraum sein. Der speicherinterne Heap 108 kann durch die Anwendung 104 verwendet werden, um Daten und Code zu speichern, die aktuell bei der Ausführung der Anwendung 104 verwendet werden. Der speicherinterne Heap 108 kann einen Teil des virtuellen Heap 110 oder den gesamten virtuellen Heap 110 umfassen. Wenn die Anwendung 104 Code oder Daten benötigt, die aktuell nicht in dem Heap 108 sind, so können eine oder mehrere Abschnitte des virtuellen Heap 110 in den speicherinternen Heap 108 kopiert werden. Wenn es in dem speicherinternen Heap 108 nicht genügend Platz gibt, können einer oder mehrere Abschnitte des speicherinternen Heap 108 aus dem Heap 108 entfernt werden, bevor die neuen Abschnitte kopiert werden. Wenn einer oder mehrere Abschnitte, die aus dem Heap 108 entfernt werden, verunreinigt (dirty) sind (d.h. wenn sie überschrieben wurden), so können die einen oder mehreren verunreinigten Abschnitte in den virtuellen Heap 110 geschrieben (gespült bzw. ausgeschwemmt) werden, bevor sie aus dem speicherinternen Heap 108 entfernt werden.
Die Anwendung 104 kann neuen Code und Daten in Abschnitten des speicherinternen Heap 108 erzeugen. Der neue Code und die Daten in dem speicherinternen Heap können in den virtuellen Heap 110 gespült werden.
Der speicherinterne Heap 108 kann einen Bereich des virtuellen Heap 110 umfassen, der für die Verwendung durch die Anwendung 104 in einem Cache aufgenommen ist (welcher als physikalischer Speicher wirkt). In einer Ausführungsform kann der Adreßraum des virtuellen Heap in Seiten mit fester Größe aufgeteilt sein. Operationen der Seitenein- und Ausgabe können verwendet werden, um Seiten aus dem virtuellen Heap 110 in dem Speicher 120 in den speicherinternen Heap 108 zu verschieben oder um Seiten aus dem Heap 108 auszustoßen. Seiten, Seitenzustände und Seitenadressierung werden noch weiter in den 2, 3 und 4 veranschaulicht.
Zu gewissen Zeiten kann ein Fixpunkt für die Anwendung 104 in den dauerhaften bzw. persistenten Speicherraum 120 geschrieben werden. In dieser Anwendung ist ein Fixpunkt eine dauerhafte Speicherung des Zustandes einer Anwendung und seiner Ausführungsumgebung (wie z.B. der Zustand der virtuellen Maschine) zu einem gegebenen Zeitpunkt. Nach dem Speichern eines Fixpunktes für die Anwendung 104 kann der dauerhafte Speicherraum 120 eine vollständige aktuelle Kopie des virtuellen Heap 110 umfassen. In einer Ausführungsform kann der dauerhafte Speicherraum 120 auch eine vollständige Kopie des virtuellen Heap für eine oder mehrere weitere Anwendungen enthalten. In einer Ausführungsform kann der dauerhafte Speicherraum 120 eine oder mehrere Versionen von Kopien des virtuellen Heap (Zustände an Fixpunkten) für jede Anwendung umfassen.
Der virtuelle persistente Heap kann erlauben, daß eine Anwendung auf einem physikalischen Heap 108 läuft, welche wesentlich kleiner ist als es ansonsten erforderlich wäre. Beispielsweise kann der virtuelle persistente Heap 110 um eine Größenordnung größer sein als der physikalische, speicherinterne Heap 108. In einer Ausführungsform kann der virtuelle persistente Heap in einem nicht flüchtigen Speicher außerhalb des Gerätes, auf welchem die Anwendung läuft, aufbewahrt werden, und Teile des Heap für den aktuellen Ausführungszustand der Anwendung können in einem Cache eines physikalischen Heap aufgenommen und aus diesem ausgegeben werden, der sich in dem lokalen Speicher auf dem Gerät befindet. Beispielsweise hat das Gerät eine Verbindung zu einem Server im Internet. Der Server kann einen nicht-flüchtigen Speicherraum für den virtuellen persistenten Heap bereitstellen. In einer anderen Ausführungsform kann der externe Speicher für den virtuellen persistenten Heap auf einem nicht-flüchtigen Speicher auf dem Gerät resident sein, beispielsweise einer Flash-Karte oder eine Festplattenlaufwerk.
Aufgrund von Persistenz bzw. Dauerhaftigkeit kann eine Anwendung mit Fixpunkten versehen und auf einer virtuellen Maschine ausgesetzt (unterbrochen) werden und eine zweite Anwendung kann dann mit ihrer Ausführung auf der virtuellen Maschine starten, ohne daß der Prozeß der virtuellen Maschine beendet werden muß. Dies vermeidet die Zusatzlast des Startens einer neuen virtuellen Maschine für eine neue Anwendung. Beispielsweise kann eine virtuelle Maschine auf einem System gestartet werden, wenn man eine erste Anwendung laufen lassen muß. Wenn eine zweite Anwendung gestartet wird, braucht der Webbrowser keine zweite virtuelle Maschine zu starten, um die zweite Anwendung laufen zu lassen, wie dies im Stand der Technik geschieht, sondern kann stattdessen für die erste Anwendung einen Fixpunkt setzen und diese aussetzen, und dann in die zweite Anwendung auf derselben virtuellen Maschine laufen lassen, auf welcher auch die erste Anwendung lief. Die zweite Anwendung kann an irgendeinem Punkt ebenfalls mit einem Fixpunkt versehen und ausgesetzt werden und die erste Anwendung kann an dem vor ihrer Aussetzung zuletzt mit einem Fixpunkt versehenen Zustand die Ausführung wieder aufnehmen. In einem anderen Beispiel kann ein Webbrowser eine virtuelle Maschine starten, um eine erste Anwendung laufen zu lassen. Der Webbrowser kann die virtuelle Maschine aktiv lassen, nachdem die erste Anwendung abgeschlossen wurde, und kann sie später erneut verwenden, um eine zweite Anwendung laufen zu lassen. Im Stand der Technik hätte das Beenden einer Anwendung bewirkt, daß die Maschine, auf welcher sie lief, die Ausführung ebenfalls beendet hätte, was erfordert, daß für jede Anwendung eine neue virtuelle Maschine gestartet wird.
Der virtuelle persistente Heap kann das Bewahren bzw. Speichern des gesamten Zustandes des virtuellen Speicherheap für eine mögliche künftige Wiederaufnahme der Berechnung an dem Punkt, an welchem die Speicherung vorgenommen wurde, ermöglichen und kann die Migration der Berechnung zu einem anderen System erlauben. In einer Ausführungsform kann der aufbewahrte bzw. gespeicherte Zustand des Heap der virtuellen Maschine auch die Fähigkeit gewährleisten, die virtuelle Maschine an einem zuvor gespeicherten, persistenten Zustand erneut zu starten, nachdem ein Systemzusammenbruch oder Abschalten erfolgt ist. Dieses Dauerhaftig keitsmerkmal kann zweckmäßig sein für kleinere Verbraucher- und Anwendungsgeräte, einschließlich Java-fähiger Geräte, wie z.B. Mobiltelefone und persönlicher digitaler Assistenten (PDAs), da diese Anwendungsgeräte häufig abgeschaltet und wieder neu gestartet werden können. Der virtuelle dauerhafte Heap kann den gesamten Adreßraum des Heap der virtuellen Maschine umfassen, den eine Anwendung verwendet.
Ausführungsformen des virtuellen persistenten Heap können zumindest eines der folgenden Methoden umfassen, nämlich eine Cachemethode, eine Datenbankspeichermethode und eine Abfallsammelmethode, wie sie nachstehend beschrieben werden.
1b – Ein Gerät mit einem außerhalb des Gerätes liegenden virtuellen persistenten Heap
1b veranschaulicht eine Ausführungsform der Erfindung, bei welcher ein Gerät 140 einen Client 101 umfaßt und Speicherraum 117, welcher außerhalb des Client liegt, den dauerhaften Speicherraum 120 für den virtuellen Heap 110 bietet. Der Speicher 117 kann auf irgendeinem Gerät vorhanden sein, der außerhalb des Clientgerätes 140 liegt, jedoch mit diesem verbunden ist. Beispiele von Verfahren, in welchen die Geräte angeschlossen sind, umfassen eine drahtlose Verbindung (Mobiltelefone, drahtloses Zugriffsprotokoll (WAP)), Infrarot (IrDA), Ethernet, den Universal Serial Bus (USB) und Telefone/Moderns, ohne jedoch hierauf beschränkt zu sein. Die Verbindung kann eine Internetverbindung sein. Der Speicher 117 kann ein flüchtiger Speicher sein, wie z.B. direkte Inline-Speichermodule (DIMMs) oder kann eine nicht-flüchtige Speichereinrichtung sein, wie z.B. ein Flash-Speicher, eine Festplatte oder eine herausnehmbare Platte wie z.B. eine Diskette. Diese Ausführungsform kann dauerhaften Speicherraum 120 in dem Speicher 117 verwenden, um den virtuellen Heap 110 für die Anwendung 104 zu speichern. Der dauerhafte Speicherraum 120 kann auch virtuelle Heaps (nicht dargestellt) für eine oder mehrere weitere ausgesetzte Anwendungen auf dem Gerät 140 umfassen. Der dauerhafte Speicherraum 120 kann weiterhin virtuelle Heaps (nicht dargestellt) für eine oder mehrere Anwendungen umfassen, die auf anderen Geräten als in dem Gerät 140 laufen.
Die Architektur und die Arbeitsweise des speicherinternen Heap 108 und des virtuellen Heap 110, wie sie in 1b dargestellt sind, kann im wesentlichen ähnlich der in 1a beschriebenen sein. In der in 1b dargestellten Ausführungsform können die Cache-Speicherung, die Fixpunkterstellung und andere Lese- oder Schreibvorgänge in den virtuellen Heap 110 über eine externe Schnittstelle, wie z.B. einen Netzwerkanschluß, durchgeführt werden, anstatt über eine interne Schnittstelle, wie z.B. einen Speicherbus, ausgeführt zu werden, wie es in der in 1a dargestellten Ausführungsform der Fall ist.
1c – Ein Gerät mit einem virtuellen persistenten Heap innerhalb des Gerätes und einem persistenten Speicher außerhalb des Gerätes
1c veranschaulicht eine Ausführungsform der Erfindung, bei welcher eine Einrichtung bzw. ein Gerät 140 einen Client 101 und einen Speicher 115 umfaßt. Der Speicher 115 kann einen virtuellen Heap 110 umfassen. Diese Ausführungsform kann außerdem einen Speicher 117 umfassen, der außerhalb des Client liegt. Der Speicher 117 kann dauerhaften Speicherraum 120 zum Aufbewahren von Fixpunkten 111 des virtuellen Heap 110 umfassen. Der Speicher 117 kann sich auch auf einem Gerät befinden, das außerhalb des Clientgerätes 140 liegt, jedoch mit diesem verbunden ist. Beispiele von Verfahren oder Methoden, mit welchen die Geräte gekoppelt sein können, umfassen: eine drahtlose Verbindung (Mobiltelefone, drahtloses Zugriffsprotokoll (WAP)), Infrarot (IrDA), Ethernet, den universellen seriellen Bus (USB) und Telefone/Modems, ohne jedoch hierauf beschränkt zu sein. Die Verbindung bzw. der Anschluß kann ein Internetanschluß sein. Alternativ kann der Speicher 117 in das Gerät 140 integriert oder direkt an diesem angebracht sein. Der Speicher 117 kann ein flüchtiger Speicher sein, wie z.B. in Form eines oder mehrerer Speichermodule (beispielsweise direkte Inline-Speichermodule (DIMMs)), oder eine nicht-flüchtige Speichereinrichtung, wie z.B. ein Flash-Speicher, eine Festplatte oder eine herausnehmbare Platte, wie z.B. eine Diskette. Diese Ausführungsform kann dauerhaften Speicherraum 120 in dem Speicher 117 verwenden, um die Fixpunkte 111 des virtuellen Heap 110 für die Anwendung 104 zu speichern. Der dauerhafte Speicher 120 kann auch Fixpunkte von virtuellen Heaps (nicht dargestellt) für eine oder mehrere ausgesetzte Anwendungen auf dem Gerät 140 umfassen. Der dauerhafte Speicherraum 120 kann auch Fixpunkte von virtuellen Heaps (nicht dargestellt) für eine oder mehrere Anwendungen umfassen, die auf Geräten laufen, die nicht das Gerät 140 sind.
Die Architektur und die Arbeitsweise des speicherinternen Heap 108 und des virtuellen Heap 110 können der zu 1a beschriebenen im wesentlichen ähnlich sein. Periodisch kann ein Fixpunkt 111 eines virtuellen Heap 110 für die Anwendung 104 in den dauerhaften Speicherraum 120 geschrieben werden. Nach dem Speichern eines Fixpunktes für die Anwendung 104 kann der dauerhafte Speicherraum 120 eine vollständige aktuelle Kopie des virtuellen Heap 110 umfassen. Der dauerhafte Speicherraum 120 kann auch Fixpunktkopien des virtuellen Haufens für eine oder mehrere andere Anwendungen umfassen.
Einige Ausführungsformen können eine oder mehrere Versionen des virtuellen Heap 110 mit Fixpunkten versehen. Beispielsweise können in der in 1c dargestellten Ausführungsform mehrfache Versionen eines Fixpunktes 111 für den virtuellen Heap 110 für die Anwendung 104 in dem dauerhaften Speicherraum 120 gespeichert werden. Es kann auch ein Verfahren bereitgestellt werden, um eine Fixpunktversion aus einer oder mehreren Fixpunktversionen auszuwählen, um die Anwendung und/oder die Ausführung der virtuellen Maschine an einem bestimmten Punkt wieder aufzunehmen.
1d – Ein Client-Serversystem mit dauerhaftem Speicherraum
1d ist ein Blockdiagramm, welches ein Netzwerk einschließlich eines Clientsystems 110, eines Gatewayservers 112 und eines Serversystems 116 gemäß einer Ausführungsform der Erfindung zeigt. Das Serversystem 116 kann einen Server 118 eines Service-Providers bzw. Dienst-Providers umfassen, beispielsweise ein Jini- oder ein anderes Netzwerkdienstanschlußsy stem oder einen Server eines kompakten Dienstanschlußsystems bzw. Dienstverbindungssystems.
Jini^TM
Jini von Sun Microsystems ist ein Beispiel eines Netzwerkverbindungssystems (NSCS), welches für Netzwerkgeräte verwendet werden kann, um Ressourcen, die hier als Dienste bezeichnet werden, auf Netzwerksystemen einschließlich Servern zu lokalisieren und zu leasen bzw. zu mieten, und um Information an Dienste, die auf den über ein Netzwerk verbundenen Systemen lokalisiert sind, weiterzuleiten und von diesen zu bekommen.
Die Jini-Technologie macht es möglich, daß eine Anwendung lokale und entfernte Dienste entdeckt und verwendet. Ein lokaler Dienst kann ein Dienst sein, der auf demselben Gerät bereitgestellt wird wie die Anwendung. Ein entfernter Dienst kann ein Dienst sein, der durch ein Gerät bereitgestellt wird, das ein anderes ist, als das Gerät, auf welchem die Anwendung läuft. Weiterhin können Anwendungen, welche derartige lokale und entfernte Dienste verwenden, Überlassungen (Mieten) der Dienste erhalten. Diese Überlassungen können nach einer gewissen Zeit (oder auf Anforderung) erlöschen. Durch Modifizieren einer Anwendung, so daß sie Jini verwendet, wenn sie auf lokale und entfernte Dienste zugreift (und um das Erlöschen und die Reaktivierung einer Überlassung bzw. Miete zu handhaben), kann das Problem des Aufbewahrens des externen Zustandes eines Prozesses während der Prozeßmigration behandelt werden.
Das Jini-System verbündet Computer und Computereinrichtungen auf einem Netzwerk zu etwas, was für den Benutzer als ein einziges System erscheint. Jedes Jinitechnik-fähige Gerät hat vorzugsweise etwas Speicher und Verarbeitungskapazität. Geräte ohne Verarbeitungskapazität oder Speicher können mit einem Jini-System verbunden werden, jedoch werden derartige Geräte möglicherweise durch weitere Hardware und/oder Software, die Proxy genannt werden, kontrolliert, die das Gerät dem Jini-System anbieten und die ihrerseits sowohl Verarbeitungskapazität als auch Speicher enthalten.
Das Jini-System konzentriert sich auf die Sun Java-Technologie. Die Jini-Architektur geht von der Annahme aus, daß die Java-Programmiersprache die Implementierungssprache für Komponenten ist. Die Fähigkeit, Code dynamisch herunterzuladen und laufenzulassen ist für eine Anzahl von Merkmalen der Jini-Architektur zentral. Es kann jedoch durch ein Jini-System jede beliebige Programmiersprache unterstützt werden, wenn es einen Compiler (Übersetzer) hat, der kompatible Bytecodes für die Java-Programmiersprache erzeugt.
Dienste (Services)
Ein Dienst ist eine Einheit, die durch eine Person, ein Programm oder einen anderen Dienst verwendet werden kann. Ein Dienst kann eine Berechnung, ein Speicher, ein Kommunikationskanal zu einem anderen Benutzer, ein Softwarefilter, ein Hardwaregerät oder ein anderer Benutzer sein. Dienste können lokal oder entfernt sein. Ein lokaler Dienst kann auf demselben Gerät bereitgestellt sein wie der Benutzer des Dienstes. Ein Benutzer eines Dienstes kann ein Client genannt werden und der Geräteclient, von welchem auf den Dienst zugegriffen wird, kann das Clientgerät genannt werden. Ein Client kann also auf einen Dienst auf dem Clientgerät zugreifen. Ein entfernter Dienst steht womöglich auf einem Gerät bereit, das ein anderes ist als das Clientgerät (außerhalb dieses Clientgerätes liegt). Beispiele von Diensten umfassen Geräte wie z.B. Drucker, Anzeigen oder Festplatten, Software, wie z.B. Anwendungen oder Hilfsprogramme, Information, wie z.B. Datenbanken und Dateien, und Benutzer des Systems sowie Übersetzungen von einem Wordprozessor-Format in irgendein anderes. Jini-Systeme stellen Mechanismen bereit für den Dienstaufbau, das Nachschlagen, die Kommunikation und die Verwendung in einem verteilten System. Dienste in einem Jini-System kommunizieren miteinander durch Verwendung eines Dienstprotokolls, das aus einem Satz von Schnittstellen besteht, die in der Java-Programmiersprache geschrieben sind.
Dienste können gefunden und genutzt werden unter Verwendung eines Nachschlagedienstes. Der Nachschlagedienst ist möglicherweise der zentrale Start- bzw. Kreislaufmechanismus für das System und kann einen Hauptpunkt für den Kontakt zwischen dem System und Benutzern des Systems bereitstellen. Genauer gesagt bildet ein Nachschlagedienst Schnittstellen, welche die durch einen Dienst bereitgestellte Funktionalität anzeigen, auf einen Satz von Objekten ab, welche den Dienst implementieren. Zusätzlich ermöglichen beschreibende Einträge, die zu einem Dienst gehören, eine genauere Auswahl von Diensten auf der Basis von Eigenschaften, die Menschen verstehen können.
Ein Dienst wird einem Nachschlagedienst hinzugefügt durch ein Paar von Protokollen, die Entdeckung und Anschluß (Discovery und Join) genannt werden. Der Dienst lokalisiert zunächst einen geeigneten Nachschlagedienst (unter Verwendung des "Discovery"-Protokolls) und schließt sich dann durch Verwendung des "Join"-Protokolls dem Nachschlagedienst an.
Dienstleasing
Ein Zugriff auf viele der Dienste in der Jini-Systemumgebung beruht auf Leasing bzw. Überlassung. Eine Überlassung ist die Gewährung eines garantierten Zugriffs auf einen Dienst für eine gewisse Zeitdauer. Ein Dienst kann eine Ressource sein, die außerhalb der virtuellen Maschine liegt, innerhalb welcher die Anwendung läuft, die einen Dienst zu haben wünscht. Ein Dienst kann ein lokaler Dienst oder ein entfernter Dienst sein. In Jini kann ein Leasing bzw. eine Überlassung zwischen dem Benutzer des Dienstes und dem Bereitsteller (Provider) des Dienstes als Teil eines Dienstprotokolls verhandelt werden: ein Dienst wird für eine gewisse Zeitdauer angefordert und Zugriff wird für eine gewisse Zeitdauer gewährt, wobei vermutlich die angeforderte Zeitdauer berücksichtigt wird. Wenn eine Überlassung nicht erneuert wird, bevor sie freigegeben wird – da der Dienst nicht mehr benötigt wird, der Client oder das Netzwerk ausfallen oder die Überlassung nicht erneuert werden darf – so können sowohl der Benutzer als auch der Bereitsteller des Dienstes übereinstimmen, daß der Dienst freigegeben werden kann. Überlassungen können exklusiv oder nicht exklusiv sein. Exklusive Überlassungen stellen sicher, daß während der Dauer der Überlassung niemand sonst eine Überlassung des Dienstes erhält; nicht-exklusive Überlassungen ermöglichen, daß mehrere Benutzer einen Dienst gemeinsam verwenden.
In einer Ausführungsform kann eine Anwendung eine oder mehrere Überlassungen für lokale und/oder entfernt gelegene Dienste bereitstellen, die außerhalb der Anwendung liegen. In einer Ausführungsform kann eine Anwendung eine oder mehrere Überlassungen von Systemcode bereitstellen, welche der Anwendung Zugriff auf Ressourcen gewährt, die außerhalb der Anwendung liegen, wie z.B. Systemressourcen. Systemcode für das Zugreifen auf eine externe Ressource kann als ein Systemdienst bezeichnet werden. Eine Überlassung von Systemcode für den Zugriff auf eine externe Ressource kann als ein überlassener Systemdienst bezeichnet werden. Beispielsweise kann eine Anwendung Überlassungen für einen Systemdienst bereitstellen, welche der Anwendung Zugriff auf Systemtreiber für das Zugreifen auf Kommunikationsanschlüsse in dem System gewährt.
In einer Ausführungsform können Wechselwirkungen zwischen Diensten und Anwendungen zustandsfrei sein. Beispielsweise kann jede Wechselwirkungs- bzw. Interaktionsanforderung durch den Empfänger gehandhabt werden, indem er die Information verwendet, die in der Anforderung enthalten ist.
Jini und JavaSpaces^TM
Das Technologiepaket JavaSpaces bietet einen verteilten Dauerhaftigkeits- und Objektaustauschmechanismus für Code, der in der Java^TM-Programmiersprache geschrieben ist. Objekte werden in Einträge geschrieben, die eine Gruppierung von relevanten Feldern nach Typen bereitstellen. Clients können einfache Operationen auf einem JavaSpaces-Server durchführen, um neue Einträge zu schreiben, nach existierenden Einträgen zu suchen und Einträge aus dem Space zu entfernen. Objekte in JavaSpaces werden in dem Java-Serialisierungsformat gespeichert. JavaSpaces-Server stellen eine dauerhafte Objektspeicherung bereit, welche traditionelle Modelle der Dauerhaftigkeit von Dateisystemspeichern ersetzt. JavaSpaces-Server stellen Systemclients für eine Netzwerkdienstverbindung, wie z.B. den Jini-Clients-Zugriff auf einen persistenten und gemeinsam verwendeten Objektspeicher bereit.
Anschlußsystem für Kleingeräte
Eine Verbraucher- oder Anwendungseinrichtung mit einem kleinen Speicherumfang kann als ein "Kleingerät" bezeichnet werden. Ein kompaktes Anschlußsystem für Netzwerkdienste (CNSCS) kann für die Verwendung mit Netzwerkclient-Kleingeräten (PDAs, Mobiltelefonen, etc.) verwendet werden, um Dienste auf Netzwerksystemen, einschließlich Servern, zu lokalisieren und zu leasen bzw. zu überlassen, und um Informationen an lokalisierte Dienste und Ressourcen und von diesen weiterzuleiten. Das CNSCS kann speziell für die Verwendung mit kleinen Netzwerkclient-Kleingeräten ausgelegt sein, die möglicherweise zu "klein" sind (d.h. nicht genug Ressourcen wie z.B. Speicher haben), um ein System, wie z.B. Jini, zu unterstützen. Das CNSCS kann als ein abgeschlossenes Nachrichtenweitergabesystem verkörpert sein, das zwischen ähn lichen kleinen Systemen arbeitet und es kann unter Verwendung eines Überbrückungsservers zu einer kompletten Jini-Vereinigung angeschlossen bzw. überbrückt werden.
CNSCS-Clients sind typischerweise Kleingeräte, die kleine Anzeigebildschirme und Tastaturen aufweisen. CNSCS-Clients können bewegliche oder stationäre Geräte sein. Beispiele mobiler CNSCS-Clients umfassen Mobiltelefone, Palmtop-Computer, Notebook-Computer, persönliche digitale Assistenten (PDAs), Desktop-Computer und Drucker, ohne jedoch hierauf beschränkt zu sein. Ein Beispiel eines nicht-mobilen (stationären) CNSCS-Client kann ein Lichtschalter sein, der einen einfachen Chip aufweist, welcher in der Lage ist, einen einfachen Satz von Befehlen (Ein/Aus) und zum Senden eines einfachen Satzes von Zustandsnachrichten (Ein/Aus-Zustand) aufweist.
Ein CNSCS-Client kann CNSCS-Kernsoftware und eine oder mehrere Clientanwendungen umfassen. Ein CNSCS-Client kann sich mit einem "festen" Netzwerk über eine Vielfalt von Pfaden verbinden. Beispiele von Verbindungs- bzw. Anschlußmethoden umfassen: eine drahtlose Verbindung (Mobiltelefone, drahtloses Zugriffsprotokoll (WAP)), Infrarot (IrDA), Ethernet und Telefone/Moderns. CNSCS-Clients können sich über Gateways mit einem Netzwerk verbinden. Die Gateways (Netzübergangsschnittstelle) bieten den Clientgeräten Zugriff auf CNSCS-Server auf dem Netzwerk. Ein Gateway kann einen Proxy-CNSCS-Server umfassen. Wenn ein CNSCS-Client angeschlossen ist, so findet er ein Netzwerk in der Nähe, auf welchem der Client eine oder mehrere Anwendungen aus dem Netzwerk laufen lassen kann. Eine oder mehrere der Anwendungen sind möglicherweise nur auf dem betreffenden Netzwerk verfügbar. Ein CNSCS-Client kann sich auch mit einem Netzwerk verbinden, um aus der Ferne auf Dateien auf einem Server zuzugreifen.
Ein mobiler CNSCS-Client kann Rundsendenachrichten verbreiten unter Verwendung irgendeiner beliebigen physikalischen Schnittstelle, die er haben mag (IrDA, WAP, persönlicher Anschluß, etc.). Alles, was für das Gerät erforderlich ist, ist, daß es Nachrichten senden und/oder empfangen kann. Einige Geräte müssen möglicherweise nur Nachrichten empfangen. Beispielsweise muß ein CNSCS-fähiger Lichtschalter wirklich nur Nachrichten empfangen und darauf reagieren (EIN-Nachricht, AUS-Nachricht oder UMSCHALT-Nachricht). Ausgeklügeltere CNSCS-Clients können eine Nachricht versenden, um sich einer CNSCS-Vereinigung anzuschließen.
Nachrichtenfähiger Netzwerkbetrieb in CNSCS
Eine verteilte Rechenmöglichkeit kann auf einer Nachrichtenschicht aufgebaut werden. Weiterhin kann eine Nachrichtenschicht (welche sowohl zuverlässige als auch nicht-zuverlässige Nachrichten bereitstellt) auf die Netzwerkanschlußklassen aufgebaut werden, die in einer eingebetteten Java-Plattform bereitgestellt werden. TCP, UDP und IP sind Beispiele von nachrichtenfähigen Protokollen, die durch CNSCS wirksam eingesetzt werden können. Andere, speziellere Protokolle wie z.B. das drahtlose Anwendungsprotokoll (WAP – Wireless Application Protocoll) sind ebenso in der Lage, CNSCS-Nachrichten zu unterstützen. WAP ist auf Netzwerke mit einer hohen Latenzzeit und geringer Bandbreite abgestimmt. CNSCS-Nachrichten arbeiten auch gut mit anderen Netzwerktreibern, wie z.B. IrDA (Infrared Data Association) und Bluetooth unterhalb des Transportes. Der einzige erforderlich Teil von CNSCS für ein Gerät (oberhalb des grundlegenden Protokoll-Stapels für den Netzwerkbetrieb) ist eine dünne Nachrichtenschicht und alle zusätzlichen Eigenschaften bzw. Möglichkeiten sind optional.
CNSCS-Spaces
Ein CNSCS-Space kann kleiner und einfacher sein als ein JavaSpace. Einige CNSCS-Spaces sind kurzlebig, während andere dauerhaft sind. Kurzlebige Spaces können verwendet werden als Rendezvous-Mechanismen für eine peer-to-peer-Kommunikation (z.B. Palm Pilot IrDA). CNSCS-Spaces von Servern können dauerhafte Objektspeicherung bereitstellen, was die traditionellen Modelle der Dauerhaftigkeit von Dateisystemspeicherung ersetzt.
CNSCS-Space-Server bieten CNSCS-Clients Zugriff auf einen persistenten (und möglicherweise gemeinsam verwendeten) Objektspeicher. In einer Ausführungsform von CNSCS können die in einem CNSCS-Space gespeicherten (und in einer Nachricht gesendeten) Objekte in XML (eXtensible Markup Language) dargestellt werden. XML kann als Mittel zur Darstellung von Objekten verwendet werden, da es ausreichend gut ausgestattet ist und auch ein Internetstandard ist.
Ein dauerhafter CNSCS-Space ist ein Verzeichnis, welches XML-Repräsentationen von Objekten enthält. Da XML verwendet wird, um den Space und seine Objekte darzustellen bzw. zu repräsentieren, können Internetsucheigenschaften wirksam genutzt werden, um Spaces und Objekte innerhalb dieser Spaces zu finden und Java- und nicht-Java-Objekte, die in C++ oder irgendeiner anderen objektorientierten Sprache erzeugt wurden, können gespeichert und von einem CNSCS-Space geholt oder in einer Nachricht angeordnet werden.
XML-Objektdarstellungen sind sprachunabhängig. In einer Ausführungsform werden nur die Daten eines Objektes in XML dargestellt, nicht sein Code. Dies bedeutet, daß Java- und nicht-Java-Anwendungen Objekte senden und voneinander empfangen können. Klassen (mit gekapseltem Bytecode) können in einem CNSCS-Space gespeichert oder in einer Nachricht weitergeleitet werden.
XML-Klassenrepräsentationen werden möglicherweise wegen Einschränkungen hinsichtlich Sicherheit und Größe nicht in allen Plattformen unterstützt. In einer Ausführungsform können Threads in XML kompiliert werden, um die Migration einer virtuellen Maschine in einen CNSCS-Space zu ermöglichen. In diesem Modell kann der CNSCS-Space als ein Speicher für einen dauerhaften Heap/virtuelle Maschine verwendet werden.
Eine virtuelle Java-Maschine versteht die Struktur eines Java-Objektes, so daß in einer Ausführungsform CNSCS JVM-Erweiterungen zum Kompilieren eines Java-Objektes in XML oder zum Dekompilieren von XML in ein Java-Objekt bereitstellen kann. In einigen Ausführungsformen kann CNSCS andere Erweiterungen zum Kompilieren und Dekompilieren anderer Objekttypen in XML oder anderen Nachrichtensprachen bereitstellen.
Space-Suche
Ein CNSCS-Client benötigt möglicherweise keinen Browser. Stattdessen kann eine Suche an einen Server abgegeben werden, der die eigentliche Suche unter Verwendung eines Eingangs-Proxy durchführt, der die Ergebnisse für den Client analysiert. Damit können CNSCS-Space-Schlangen Suchen nach Internetdokumenten sein, die durch Nachrichten, welche an einen Proxy gesandt wurden, ausgelöst wurden.
CNSCS-Leasing
Wie bei Jini kann der Zugriff auf viele Dienste in der CNSCS-Systemumgebung auf Überlassung bzw. Leasing beruhen. Eine Überlassung ist die Gewährung eines Zugriffs auf einen Dienst. In einer Ausführungsform kann eine Anwendung eine oder mehrere Überlassungen von lokalen und/oder entfernten Diensten bereitstellen, die außerhalb der Anwendung liegen. In einer Ausführungsform kann eine Anwendung eine oder mehrere Überlassungen auf Systemcode bereitstellen, die der Anwendung Zugriff auf Ressourcen gewähren, die außerhalb der Anwendung liegen, wie z.B. Systemressourcen. Der Überlassungsmechanismus kann es Clients ermöglichen, Überlassungen für Objekte in einem CNSCS-Space zu erhalten. In einer Ausführungsform kann der CNSCS-Überlassungsmechanismus eine Überlassung bzw. Leasing auf Zeitbasis verwenden. In einer anderen Ausführungsform können Clients Java-Objekte beanspruchen und eine Rückrufmethode anmelden, die aufgerufen werden kann, wenn ein anderer Client eine Überlassung haben möchte, die nicht mit den aktuellen Haltern von Überlassungen kompatibel ist. Es kann verschiedene Ebenen bzw. Niveaus von CNSCS-Überlassungen geben. Auf einem ersten Niveau wird eine Kopie des Java-Objektes möglicherweise nicht geliefert, wenn man eine Überlassung erhält, sondern es wird lediglich ein Interesse an diesem Objekt registriert, das in dem CNSCS-Space gehalten wird. Eine zweite Ebene liefert eine Kopie des Java-Objektes, wenn auf dieser Ebene eine Überlassung erhalten wird, es könnten jedoch mehrere Clients da sein, die auf das Objekt zugreifen. Auf einer dritten Ebene wird eine Kopie dieses Java-Objektes geliefert, wenn man eine Überlassung auf dieser Ebene erhält und andere Clients werden daran gehindert, auf das Objekt zuzugreifen.
In einer Ausführungsform können Interaktionen zwischen Prozessen und Diensten, welche durch Überlassungen bereitgestellt werden, zustandslos sein. Beispielsweise kann jede Interaktionsanforderung durch den Empfänger unter Verwendung von Information behandelt werden, die in der Anforderung enthalten ist.
Gemäß 1d kann der Server 118 eines Dienst-Providers einen dauerhaften Speicherraum 120 umfassen. Das Clientsystem 100 kann eine Computerplattform mit einem Betriebssystem, wie z.B. ein PC oder ein Laptop-Computer, sein, auf dem Windows 9x/NT oder eine virtuelle Maschine, beispielsweise eine JVM oder KVM, läuft, die auf der Computerplattform aufsitzt oder auf einem Verbraucher- oder Anwendungsgerät, beispielsweise einem Mobiltelefon oder PDA, abläuft. Das Clientsystem 100 kann den Client 102 eines Dienstproviders umfassen, beispielsweise einen Jini- oder CNSCS-Client, um Dienste auf entfernt gelegenen Servern zu finden und zu lesen. Das Clientsystem 100 kann verwendet werden, um Anwendungen und Applets, beispielsweise Java-Anwendungen und -Applets laufen zu lassen. Eine oder mehrere Anwendungen können auf dem Clientsystem 100 ablaufen. Die Anwendung 104 ist als eine gerade ausgeführte Anwendung dargestellt und die Anwendung 106 ist als eine ausgesetzte Anwendung dargestellt. Die Anwendung 104 kann auf einen "speicherinternen" Heap 108 zugreifen. Der dauerhafte Speicherraum 120 kann einen virtuellen Heap (110) für die Anwendung 104 umfassen. Der dauerhafte Speicherraum 120 kann auch einen virtuellen Heap (nicht dargestellt) für die Anwendung 106 umfassen.
Das Clientsystem 100 kann Nachrichten rundsenden und empfangen, unabhängig davon, welche physikalische I/O-Schnittstelle es hat (IrDA, WAP, Ethernet, Modem, spezielle persönliche Verbindung, etc.). Das Clientsystem 100 kann auf Dienste auf einem oder mehreren Servern auf dem Netzwerk, einschließlich des Servers 116, zugreifen. In einer Ausführungsform kann der Client 102 des Dienstproviders eine Verbindung zu Servern auf dem Netzwerk über den Gateway-Server 112 herstellen. Ein Gateway 112 kann einen Server 114 eines Proxydienst-Providers umfassen. Wenn der Client 102 des Service-Providers angeschlossen ist, kann er den Server 116 finden, auf welchem der Client 102 über eine Überlassung oder auf andere Weise dauerhaften Speicherraum 120 für den virtuellen Heap-Raum für eine oder mehrere Anwendungen einschließlich der Anwendungen 104 und 106 bereitstellen. Fixpunkte für Anwendungen können in dem dauerhaften Speicherraum 120 gespeichert werden. Der dauerhafte Speicherraum 120 kann also ein Dienst sein, der durch eine Anwendung, welche ein Dienstprovidersystem verwendet, wie z.B. Jini oder CNSCS, gemietet bzw. geleast werden kann.
Ein Leasing bzw. eine Überlassung kann für einen leasingfähigen Dienst 125 auf dem Server 124 bereitgestellt werden. Die Überlassung kann bereitgestellt werden für die Anwendung 104 durch den Client 102 des Dienstproviders. Der Dienstprovider 102 kann die Überlassung über den Proxy-Server 114 des Dienstproviders bereitstellen. In einer Ausführungsform können auch Überlassungen von Diensten und/oder Ressourcen auf dem Clientgerät 100 bereitgestellt werden.
Die Architektur und der Betrieb des speicherinternen Heap 108 und des virtuellen Heap 110, wie in 1d dargestellt, kann der in 1a beschriebenen im wesentlichen ähnlich sein. In der in 1d dargestellten Ausführungsform können die Cachespeicherung, die Fixpunkterstellung und andere Lese- und Schreibvorgänge in den virtuellen Heap 110 über eine Netzwerkverbindung durchgeführt werden, beispielsweise über das Internet, anstatt daß sie über eine interne Schnittstelle, wie z.B. einen Speicherbus, durchgeführt werden, wie in der in 1a dargestellten Ausführungsform.
1e – Ein virtueller Heap und Überlassungen von lokalen und entfernten Ressourcen
1e ist ein Blockdiagramm, welches einen virtuellen Heap 148 für eine Anwendung und Überlassungen von lokalen und entfernten Ressourcen gemäß einer Ausführungsform der Erfindung darstellt. Der virtuelle Heap 148 kann eine oder mehrere Seiten von Anwendungscode und Daten 152 enthalten. Der virtuelle Heap 148 kann auch eine oder mehrere Seiten von Systemcode und Daten 154 enthalten. Seiten 152 können eine Überlassung eines Dienstes 164 umfassen, der Information enthalten kann, welche die Überlassungsbeziehung zu einem Dienst 166 beschreibt. Der Dienst 166 kann ein lokaler oder ein entfernter Dienst sein. In einer Ausführungsform kann die Überlassung bereitgestellt werden unter Verwendung eines NSCS, wie z.B. Jini. In einer anderen Ausführungsform kann die Überlassung unter Verwendung eines CNSCS bereitgestellt werden.
Die Seiten 152 können auch eine Überlassung von Systemcode 156 umfassen. In einer Ausführungsform kann die Überlassung bereitgestellt werden unter Verwendung eines NSCS, wie z.B. Jini. In einer anderen Ausführungsform kann die Überlassung bereitgestellt werden unter Verwendung eines CNSCS. Die Überlassung von Systemcode 156 kann der Anwendung Zugriff auf eine Systemressource 162 gewähren, indem die ursprüngliche bzw. native Methode 158 überlassen wird. Die native Methode 158 kann Systemcode sein, der eine oder mehrere ursprüngliche bzw. native Codefunktionen 160 des Systems für den Zugriff auf die Systemressource 162 aufruft. Beispielsweise kann die Systemressource 162 ein Busanschluß, wie z.B. ein USB-Anschluß, sein. Der Code 160 kann der Treiber der ursprünglichen Sprache für den USB-Anschluß sein. Die ursprüngliche bzw. native Methode 158 kann den Code umfassen, welcher erforderlich ist, um verschiedene Funktionen aufzurufen, welche durch den USB-Treiber in der ursprünglichen Sprache bereitgestellt werden.
In einer Ausführungsform werden, wenn für die Anwendung ein Fixpunkt gesetzt wird, der Systemcode und die Datenseiten 154 möglicherweise nicht mit einem Fixpunkt versehen. Wenn der Anwendungscode und die Datenseiten 154 mit einem Fixpunkt versehen werden, können die Dienstüberlassung 164 und die Systemressourcenüberlassung 156 mit Fixpunkten versehen werden. In einer Ausführungsform kann die Information, die für eine Überlassung mit einem Fixpunkt versehen wird (Systemressourcen- oder Dienstüberlassung), genügend Information enthalten, um die Überlassung wiederherzustellen, falls erforderlich. In einer Ausführungsform können die Überlassungen von Systemressourcen und Diensten zustandslos sein, d.h. es können keine Aufzeichnungen vorheriger Interaktionen zwischen der Anwendung und dem Dienst oder der Ressource aufbewahrt werden und jede Interaktionsanforderung zwischen der Anwendung und dem Dienst oder der Ressource kann vollständig auf Basis von Information gehandhabt werden, die mit dieser geliefert wird. Zustandslos zu sein kann das Fixpunkterstellen bei Überlassungen vereinfachen, da keine aktuelle Information oder Information über vergangenen Zustand für die Überlassungen mit Fixpunkten versehen werden muß. Wenn die Anwendung zu einem anderen Gerät migrieren muß, oder wenn die Anwendung aus irgendeinem Grund ausgesetzt wird, so können die Überlassungen, die von der Anwendung gehalten werden, gelöscht werden, wobei die Dienste und/oder Ressourcen, die durch die Überlassungen gehalten wurden, freigegeben werden. Wenn die Anwendung wieder aufgenommen wird (lokal oder auf einem anderen Gerät), so kann die Überlassungsinformation von dem mit Fixpunkt versehenen Zustand der Anwendung verwendet werden, um die Überlassungen von Diensten und/oder Systemressourcen wiederherzustellen.
In einer Ausführungsform kann eine Anwendung zu einem Gerät mit einem gegenüber dem System und der nativen Sprache des Gerätes, von welchem sie migriert, unterschiedlichen System und einer anderen ursprünglichen (nativen) Sprache wandern. In dieser Ausführungsform kann die Überlassung der Systemressourcen 156 zu einer Methode 158 in dem Systemcode 154 des Gerätes wiederhergestellt werden, zu welchen die Anwendung gewandert bzw. migriert war. Ursprüngliche Codefunktionen 160 für das Zugreifen auf die Systemressource 162 können in dem nativen Code der neuen Einrichtung vorhanden sein.
In einer Ausführungsform kann die Anwendung zu einem Gerät wandern bzw. migrieren, welches keine Systemressourcen 162 hat. In diesem Fall kann die Anwendung darüber unterrichtet werden, daß die Überlassung der Systemressource nicht wiederhergestellt werden kann. In einer Ausführungsform kann die Anwendung zu einem Gerät wandern, welches keinen Zugriff auf den Dienst 166 hat. In einer Ausführungsform kann die Anwendung darüber unterrichtet werden, daß die Überlassung für den Dienst nicht wiederhergestellt werden kann. In einer Ausführungsform kann, wenn festgestellt wird, daß der Dienst 166 nicht verfügbar ist, möglicherweise ein alternativer Dienst gesucht werden, um die Funktionalität des Dienstes 166 zu erfüllen, und, wenn dies der Fall ist, so kann eine Überlassung für den alternativen Dienst bereitgestellt werden.
1f – Ein virtueller Heap und Überlassungen von Systemressourcen
1f ist ein Blockdiagramm, welches einen virtuellen Heap 148a und 148b für zwei Anwendungen mit Überlassungen von Systemressourcen 162a und 162b gemäß einer Ausführungsform der Erfindung zeigt. In dieser Ausführungsform kann ein Heap 164, der außerhalb der virtuellen Heaps 148a und 148b liegt, verwendet werden, um Systemcode und Daten zu speichern, die gemeinsam von zwei oder mehr Anwendungen verwendet werden können.
Die virtuellen Heaps 148a und 148b können jeweils eine oder mehrere Seiten von Anwendungscode und Daten 152a und 152b enthalten. Die Seiten 152a und 152b können Überlassungen von Systemcode 156a und 156b enthalten, welche der Anwendung Zugriff auf Systemressourcen 162a bzw. 162b geben, indem sie gemeinsam verwendete native Methoden 158a und 158b verleasen bzw. überlassen. Die nativen Methoden 158a und 158b können Systemcode enthalten, welcher eine oder mehrere native Codefunktionen 160 für das Zugreifen auf die Systemressourcen 162a und 162b aufrufen können. Einige Systemressourcen können gemeinsam verwendbar sein und andere können Privilegien eines exklusiven Zugriffs erfordern. In einer Ausführungsform können, wenn eine native Methode in dem Heap 154 einen gemeinsamen Zugriff erlaubt, zwei oder mehr Anwendungen Überlassungen für dieselbe native Methode, und damit für dieselbe Systemressource, gleichzeitig halten.
2 – Architektur des virtuellen dauerhaften Heap
2 ist ein Blockdiagramm, das die Architektur eines virtuellen dauerhaften (persistenten) Heap gemäß einer Ausführungsform der Erfindung zeigt. Die Anwendung 104 kann auf dem Clientsystem 100 ablaufen. Die Anwendung 104 kann den speicherinternen Heap 108 verwenden.
Der dauerhafte Speicher 120 kann auf einem Server im Netzwerk liegen, auf welchen das Clientsystem 100 Zugriff hat, oder er kann alternativ in einem lokalen, nicht-flüchtigen Speicher auf dem System liegen, auf welchem die Anwendung 104 abläuft. Die Seitentabelle 122 kann auf demselben System wie die Anwendung 104 liegen oder kann alternativ auf einem anderen System auf dem Netzwerk liegen.
Der dauerhafte Speicher 120 enthält eine vollständige Kopie des virtuellen Heap 110 (virtuelle Speicherstruktur) für die Anwendung 104. Der speicherinterne Heap 108 kann einen Teil des virtuellen Heap 110 umfassen, der im Cache aufgenommen ist (als physikalischer Speicher wirkt). In einer Ausführungsform ist der virtuelle persistente Heap ein Heap auf Seitenbasis. Der Adreßraum des virtuellen Heap ist in Seiten fester Größe aufgeteilt. Operationen für Seiteneingabe und Seitenausgabe werden verwendet, um Seiten aus dem persistenten Speicher 120 in den speicherinternen Heap zu verschieben und um Seiten aus dem speicherinternen Heap 108 auszustoßen.
In dieser Anwendung können die Begriffe "physikalischer Heap" oder "Heap" so verwendet werden, daß sie die Heap-Struktur in dem Speicher 108 anzeigen. Dies ist nur ein Teil des gesamten virtuellen Heap 110, der in dem persistenten Speicher 120 aufbewahrt wird. Der Begriff "virtueller Heap" kann verwendet werden, um das vollständige Heap-Bild anzuzeigen, welches in dem Speicher 120 gespeichert bzw. aufbewahrt wird. Der Adreßraum des "speicherinternen" Heap kann als der physikalische Speicher betrachtet werden. Der Adreßraum des Heap "im Speicher" kann als der virtuelle Speicher betrachtet werden. Der Speicher 120 kann in zwei oder mehrere, nicht zusammenhängende virtuelle Heaps aufgeteilt sein. Jede mit einem Fixpunkt versehene Anwendung, wie z.B. die Anwendung 104, hat in dem Speicher ihren eigenen virtuellen Heapraum reserviert. In einem beispielhaften dauerhaften Speicher 120 existiert ein virtueller Heapraum für die Anwendung 106 und die Anwendung 104, und zwei nicht benutzte virtuelle Heapräume existieren, um zwei weitere Anwendungen zu ermöglichen.
Der Seitenwechsel (Paging) stellt ein einfaches Modell zum Verschieben von Daten aus dem dauerhaften Speicher 120 in den speicherinternen Heap 108 in der virtuellen Maschine 100 bereit. In einer Ausführungsform kann eine Seitentabelle 122 und eine Adreßübersetzung, die auf einem Versatz (Offset) beruht, verwendet werden, um Hinweise auf bzw. Aufrufe in dem virtuellen Heap 110 in Hinweise auf bzw. Aufrufe in dem speicherinternen Heap 108 umzuwandeln. Es können relativ kleine Seiten verwendet werden, um den Abfall in dem Heap zu reduzieren. In einer Ausführungsform kann ein Ansatz auf Basis von Paging (Seitenwechsel) einen Seitenschutzmechanismus und eine Unterstützung für DMA- und Block-I/O-Geräte ermöglichen.
In einer Ausführungsform kann anstelle von Paging bzw. Seitenwechsel eine Granularität der Cacheaufnahme von Objekten implementiert sein. Die Granularität bei der Aufnahme von Objekten im Cache ist möglich, wenn Objekte in dem Heap effektiv verschoben werden können. Eine Betrachtung von Ausführungsformen, welche Objekthandhabungen verwenden, ist die Einschränkung der Speicherbasis. Der Objekthandhabungsbereich kann mehr Speicherraum beanspruchen als verwandte Strukturen, wie z.B. Handhabungstabellen in Ausführungsformen, die Seiten verwenden.
Das Verwenden von Seitenhandhabungen anstelle von Objekthandhabungen kann die Fähigkeiten bieten, die Implementierung an die Erfordernisse der Speicherbasis eines ins Auge gefaßten Gerätes anzupassen. Die Seitengröße legt die Menge an Raum fest, die für die Handhabungstabelle erforderlich ist. Größere Speicherumgebungen können kleinere Seiten verwenden. Kleinere Speicherumgebungen müssen größere Seiten verwenden. Größere Objekte können aufgebrochen sein und über mehrere Seiten hinweg gespeichert werden, was es ermöglicht, daß Teile von Objekten in dem speicherinternen Heap 108 cachegespeichert und ausgelesen werden. Dies ermöglicht es Geräten mit beschränkten Speicherressourcen, Objekte und damit Anwendungen zu unterstützen, die mit der Granularität der Objekt-Cache-Aufnahme nicht unterstützt werden können. Mit der Granularität der Objekt-Cache-Aufnahme muß möglicherweise das gesamte Objekt in dem speicherinternen Heap 108 als Cache aufgenommen werden.
Eine Ausführungsform kann einen Ansatz für die Seiteneingabe und Seitenausgabe verwenden, um Seiten von dem virtuellen Heap 110 in den speicherinternen Heap 108 zu bringen. Für Ausführungsformen, in welchen der persistente Speicher in einer Flash-Speichereinrichtung vorliegt, kann die Seitenausgabe eine Streu-/Sammelobjektphase verwenden, um nur aktuelle Objekte zu speichern, um die Lebensdauer der Flasheinrichtung zu vergrößern. In einer Ausführungsform kann dies mit einem protokollbasierten Ansatz kombiniert werden, um die Unteilbarkeit von Speichertransaktionen zu gewähren.
In einem System auf Seitenbasis kann die Seitengröße erhöht werden, um die Größe der Seitentabelle 122 zu reduzieren. Das Steigern der Seitengröße kann das Anordnen von mehreren Objekten auf einer einzelnen Seite ermöglichen. In diesem Fall kann ein einzelner Seitentabelleneintrag die Rolle von mehreren Objekthandgriffeinträgen haben (ein Handgriff für jedes Objekt auf der Seite). Das Gruppieren von Objekten in einem einzelnen Tabelleneintrag kann die Reduzierung der Speicherbasis, die für die Handhabung einer Seitentabelle erforderlich ist, ermöglichen, da es möglicherweise weniger Handgriffe gibt. Das Aktualisieren eines einzelnen Objektes auf der Seite kann das Schreiben der gesamten Seite (alle Objekte auf der Seite) erfordern. Andererseits ermöglicht das Reduzieren der Seitengröße, daß nur wenige Objekte auf einer Seite gespeichert werden, so daß die Granularität beim Seitenwechsel bzw. der Seitenverwaltung vermindert wird. Dieser Ansatz kann die Größe der Seitentabelle erhöhen. Die Seitengröße kann dementsprechend auf der Basis der Speichereinschränkungen des Gerätes, auf welchem das auf Seitenwechsel bzw. Seitenverwaltung basierende System implementiert ist, eingestellt werden.
In einer Ausführungsform kann der virtuelle Heap 110 in eine feste Anzahl von Seiten aufgeteilt werden. In einer Ausführungsform kann die Größe des virtuellen Heap der Anwendung (d.h. der Kern zuzüglich aller Benutzerseiten) ein festgelegtes Vielfaches der Größe des spei cherinternen Heap 108 sein, um eine effiziente Adreßübersetzung zu unterstützen. Dies ermöglicht es jedem virtuellen Heapspeicher der Anwendung, bei einem Versatz eines Mehrfachen der Heapgröße in dem persistenten Speicher 120 zu beginnen. In dieser Ausführungsform enthält die Adreßübersetzung das Abziehen eines mehrfachen der festgelegten Heapgröße. Da eine virtuelle Maschine möglicherweise keinen Zugriff auf einen Hardware-Übersetzungsmechanismus hat, kann die Adreßübersetzung vereinfacht werden, so daß sie in effizienter Weise in Software durchgeführt werden kann.
Ein Schema auf Offsetbasis kann verwendet werden, um eine Adresse eines virtuellen Heap in eine Adresse eines speicherinternen Heap umzuwandeln. Alle Objektaufrufe in dem virtuellen Heap 110 und dem speicherinternen Heap 108 können als virtuelle Heap-Adressen gehalten werden. In einer Ausführungsform kann es eine Adreßübersetzung geben, um die virtuelle Heapadresse in die physikalische Heap-Position umzuwandeln. Die CPU des Systems oder die CPU-Schicht der virtuellen Maschine kann eine Adreßübersetzung aus dem Adreßraum des virtuellen Heap in die Position bzw. Speicherstelle des speicherinternen Heap über einen Eintrag in der Seitentabelle 122 durchführen. Die Seitentabelle 122 hält die Abbildung bzw. Zuordnung der Seite des virtuellen Heap 110 in den Heap 108. Für jeden Adreßaufruf in dem virtuellen Heap 110 (Lesen oder Schreiben), kann Code eingefügt werden (Lese-Schreib-Begrenzungen), um die Gültigkeit der Adresse zu verifizieren (d.h. überprüfen, ob die entsprechende Seite in dem Heap liegt), und um sie in einem Aufruf in dem speicherinternen Heap 108 zu übersetzen. Der Prozeß des Umwandelns von Heap-Adressen ist in 4 dargestellt.
In einigen Ausführungsformen kann die CPU-Schicht der virtuellen Maschine, beispielsweise die Java-CPU-Schicht, Zugriff auf Adreßübersetzungsfunktionen einer Hardware-Speicherverwaltungseinheit (MMU) bereitstellen, was es erlaubt, daß Objekt-Handhabungsumleitungen in Hardware erfolgen.
In einer Ausführungsform kann ein Objekt in dem virtuellen Adreßraum Aufrufe von anderen Objekten über eine gültige oder eine ungültige Adresse halten. Eine gültige Adresse kann bedeuten, daß die entsprechende Seite in dem speicherinternen Heap 108 liegt (residiert). Eine ungültige Adresse kann bedeuten, daß die betreffende Seite nicht in dem speicherinternen Heap 108 liegt.
Seitentabelle 122
In einer Ausführungsform ist die Seitentabelle 122 nicht persistent, sondern ist eine "lebendige" Struktur. Die Seitentabelle kann neu initialisiert werden, wann immer eine neue Anwendung wieder gestartet wird. In einer Ausführungsform kann die Seitentabelle 122 einen oder mehrere der folgenden Einträge für eine Seite des virtuellen Heap 110 der aktiven Anwendung umfassen:

• Typ (Benutzer oder System): Der Seitentyp wird verwendet, um die Durchschreibestrategie auszuwählen, die verwendet wird, um die Seite in dem dauerhaften Speicher 120 durch Backup zu sichern, ebenso wie die Seitenwechselstrategie bzw. Seitenverwaltungsstrategie auszuwählen (welche Seite ausgestoßen werden soll). Beispielsweise können Systemseiten in dem speicherinternen Heap 108 festgesetzt werden und können nicht ausgelagert werden.
• Resident (wahr oder falsch): In einer Ausführungsform kann das Residenz-Bit verwendet werden, um den Residenzzustand der Seite in dem Heap zu halten und es kann auf "wahr" (TRUE) gesetzt sein, wenn die Seite in dem Heap 108 resident ist, oder auf "falsch" (FALSE) gesetzt sein, wenn die Seite nicht in dem Heap 108 resident ist. In einer anderen Ausführungsform kann ein Wert, der in einem ID-Feld der Heapseite gespeichert ist, verwendet werden, um anzuzeigen, ob eine Seite in dem Heap resident ist. Wenn beispielsweise eine Speicheradresse verwendet wird, um die Identität der Heapseite anzuzeigen, kann eine NULL-Adresse oder eine andere ungültige Adresse verwendet werden, um anzuzeigen, ob die Seite resident ist. In einer weiteren Ausführungsform können nur Seiten, die aktuell in dem speicherinternen Heap 108 in Cacheform aufgenommen sind, einen Eintrag (Reihe) in der Seitentabelle 122 haben.
• Verunreinigt (wahr oder falsch): Verfolgt jegliches Schreiben oder Modifikation der Seite in dem Heap 108. Ist auf "wahr" (TRUE) gesetzt, wenn die Seite verunreinigt ist (modifiziert wurde oder überschrieben wurde).
• Spülen (wahr oder falsch): Nur gültig für verunreinigte Seiten. Zeigt an, daß die Seite sich in der Fixpunktschlange befindet. Wenn auf "wahr" (TRUE) gesetzt, so befindet die Seite sich in der Liste von Seiten, die in den virtuellen Heap 110 in dem Speicher 120 ausgespült werden sollen.
• Heap-Seiten-ID: Gibt die Position der Seite in dem Heap 108 an.

In einer Ausführungsform, wie sie in 2 dargestellt ist, gibt es einen Eintrag in der Seitentabelle 122 für jede Seite des virtuellen Heap 110 der aktiven Anwendung. Diese Ausführungsform kann die Position eines Eintrags für eine Seite in der Seitentabelle 122 vereinfachen. In einer anderen Ausführungsform gibt es vielleicht nur einen Eintrag in der Seitentabelle für jede Seite, die aktuell in den Cache in dem speicherinternen Heap 108 cachegespeichert ist. Diese Ausführungsform kann die Größe der Seitentabelle 122 vermindern.
Nur-Lese/statische Kernobjekte der virtuellen Maschine können in festgesetzten und nur für das Lesen vorgesehenen Systemseiten angeordnet sein (Objekte können durch den primären Klassenlader mit Tags versehen sein). Diese Klassen werden typischerweise nicht zweimal geladen. Das Lesen/Schreiben von Kernobjekten der virtuellen Maschine kann auf Benutzerseiten angeordnet werden. In einer Ausführungsform können Kernobjekte der virtuellen Maschine für das Lesen/Schreiben als Systemseiten "gefärbt" sein. Alle Benutzerobjekte können Benutzerseiten zugewiesen sein.
In einer Ausführungsform kann eine Anwendung eine oder mehrere Überlassungen von Systemobjekten bereitstellen, welche der Anwendung Zugriff auf Ressourcen außerhalb der Anwendung, wie z.B. Systemressourcen, gewähren. In einer Ausführungsform können die System seiten in einem Heap Systemobjekte (Code und/oder Daten) umfassen, die aktuell geleast bzw. überlassen sind. In einer Ausführungsform können die Überlassungen für die Systemobjekte in dem virtuellen Heap 110 der Anwendung enthalten sein.
In Ausführungsformen, die zu einem gegebenen Zeitpunkt nur eine Anwendung laufen lassen, kann jeder virtuelle Heap einer Anwendung seinen eigenen Satz von Systemseiten enthalten. In diesen Ausführungsformen werden Systemseiten nicht von Anwendungen gemeinsam verwendet. In Ausführungsformen, auf welchen zu einem gegebenen Zeitpunkt mehr als eine Anwendung läuft, können die Systemseiten von den Anwendungen gemeinsam verwendet werden. Diese Ausführungsformen haben möglicherweise ein Systemsegment in dem dauerhaften Speicher 120, um statische und Nur-Lese-Seiten mit Fixpunkten zu versehen, die von den Anwendungen sicher gemeinsam verwendet werden können.
3 – Die Zustände einer Seite in einem virtuellen, persistenten Heap
3 ist ein Zustandsdiagramm, welches die Zustände einer Seite in einem virtuellen persistenten Heap gemäß einer Ausführungsform der Erfindung zeigt. Eine Seite kann sich in einem der folgenden Zustände befinden:

• Leer: Die Seite ist freigegeben worden oder ist nicht zugeordnet worden.
• Resident: Die Seite ist neu zugeordnet worden oder die Seite ist durch Seitenwechsel von dem virtuellen Heap 110 in dem dauerhaften Speicher 120 in den speicherinternen Heap 108 aufgenommen worden. Es sind keine Änderungen an der Seite vorgenommen worden oder die letzten Änderungen sind in den dauerhaften Speicher 120 ausgespült worden. Die Kopie in dem Heap 108 wird mit der Kopie in dem Speicher 120 synchronisiert.
• Verunreinigt: Ein Schreiben ist auf der Seite durchgeführt worden und die Seite ist nicht in den dauerhaften Speicher 120 zurückgeschrieben worden. Es hat keine Anforderung einer Fixpunkterstellung für die Seite gegeben.
• Warten auf Versehen mit einem Fixpunkt: Die Seite befindet sich in einer Liste von Seiten, die für den Speicher 120 mit Fixpunkten zu versehen sind. Die Seite ist aktuell gegen Schreiben gesperrt, so daß kein weiteres Schreiben erfolgen kann, bis die Seite ausgespült worden ist.
• Persistent: Die Seite ist ausgelagert worden. Die Seite ist nicht mehr in dem Heap 108 resident.

Seitenfehler
Ein Seitenfehler tritt auf, wenn ein Aufruf auf eine Seite vorgenommen wird, die nicht in dem speicherinternen Heap 108 vorhanden ist. Der Seitenfehler kann eine Cacheaufnahme der Seite aus dem virtuellen Heap 110 in dem Speicher 120 in dem Heap 108 auslösen. Wenn ein Seitenfehler auftritt, können die folgenden Zustände auftreten:

• Eine freie Seite ist in dem Heap 108 verfügbar: die Seite kann in den Heap 108 gebracht werden und der Eintrag in der Seitentabelle 122 wird aktualisiert.
• Es gibt keine freien Seiten in dem Heap 108: bevor die Seite in Cache aufgenommen werden kann, muß Platz in dem Heap geschaffen werden. Eine oder mehr residente Seiten müssen aus dem Heap 108 herausgenommen werden.

In einer Ausführungsform können, wenn man nach möglichen Kandidaten von Seiten sucht, die herausgeworfen werden sollen, mehr als eine Seite für das Herauswerfen ausgewählt werden, da es wahrscheinlich ist, daß bald eine weitere Seite herausgeworfen werden muß. In einer Ausführungsform kann ein Grenzwert für freie Seiten verwendet werden, um dieses Verhalten auszulösen. In einer Ausführungsform kann ein standardmäßiges LRU (zuletzt verwendet) – Verfahren verwendet werden, um Seiten für das Auswerfen (Seiten auslagern) auszuwählen. In anderen Ausführungsformen können andere Methoden, beispielsweise am wenigsten häufig verwendet (least frequently used – LFU) verwendet werden, um Seiten für das Hinauswerfen auszuwählen.
Wenn eine Seite verunreinigt ist, so kann die Seite mit Fixpunkten in den Speicher 120 aufgenommen werden, oder alternativ kann eine Schattenkopie gemacht werden, bevor sie aus dem Heap 108 freigegeben wird. In einer Ausführungsform können nicht-verunreinigte Seiten vor verunreinigten Seiten ausgeworfen werden.
Fixpunkterstellen von Seiten
Wie zuvor beschrieben, können Seiten in den Heap 108 gebracht, modifiziert und mit Fixpunkten in den virtuellen Heap 110 in dem Speicher 120 aufgenommen werden, wenn sie ausgestoßen werden. In einer Ausführungsform können die Seiten mit Fixpunkten versehen werden, wenn sie ausgewiesen werden. Alternativ können Seiten mit Fixpunkten versehen werden, wenn sie in dem Heap 108 verbleiben. Wenn beispielsweise die Fixpunkterstellung asynchron durchgeführt werden kann (ein ausführender Thread muß nicht eingefroren werden), so können die Seiten mit Fixpunkten versehen werden, wann immer dies zweckmäßig erscheint, mit einem Minimum an Zusatzlast, um nach verunreinigten Seiten zu suchen.
In Ausführungsformen mit einer virtuellen Maschinenumgebung mit einzelnen Threads, die eine einfache Bytecodezählung als ein Zeitaufteilungsmaß für das Umschalten zwischen Threads verwendet, kann nach Seiten, die mit Fixpunkten versehen sind, gesucht werden, wann immer eine Thread-Synchronisierung oder eine Kontextumschaltung erfolgt. Bei einer Thread-Kontextumschaltung kann nach verunreinigten Seiten gescannt werden und sie können in einer Fixpunktschlange angeordnet werden. In einer anderen Ausführungsform kann ein Mechanismus zum Unterbrechen des laufenden Thread verwendet werden, um eine Gelegenheit für das Suchen und mit Fixpunktversehen von Seiten bereitzustellen.
Das Spülbit in der Seitentabelle 122 kann verwendet werden, um Seiten zu markieren, die sich in der Fixpunktschlange befinden. Weitere Schreibvorgänge auf die Seite können verhindert werden, während die Seite sich in der Schlange oder in dem Vorgang, mit Fixpunkt versehen zu werden, befindet. In einer Ausführungsform kann der Strang (Thread) blockiert werden, bis die Seite geschrieben worden ist. In dieser Ausführungsform kann die Fixpunktschlange neu geordnet werden, um Seiten in der Priorität hochzusetzen, die einen blockierten Thread haben. In einer anderen Ausführungsform kann eine Kopie der Seite gemacht werden, um den Thread auf die Schattenkopie "übergehen" zu lassen. Eine gerade erst mit Fixpunkt versehene Seite kann nicht sofort in die Fixpunktschlange zurückgeschoben werden.
Systemseiten können andere Fixpunktstrategien als Benutzerseiten haben. Beispielsweise kann die Fixpunkterstellung von Systemseiten die gesamte virtuelle Maschine einfrieren. Systemseiten können daher gezielter für die Fixpunkterstellung ausgewählt werden als Benutzerseiten.
Speichern von Fixpunkten und Konsistenz
Das individuelle Fixpunkterstellen für Seiten kann unzureichend sein, um die Konsistenz des virtuellen Heap 110 in dem Speicher 120 aufrechtzuerhalten. Wenn beispielsweise zwei Seiten in dem Heap 108 ausgetauscht wurden, jedoch nur eine Seite mit Fixpunkten versehen worden ist und das System zusammenbricht, kann der mit den Fixpunkten versehene virtuelle Heap in dem Speicher 120 in einem inkonsistenten Zustand enden. Wenn das System mit einem inkonsistenten Speicher 120 erneut startet, kann die Anwendung aufgrund fehlerhafter Zeigerpositionen abstürzen. Es gibt keine Garantie, daß Seiten, die in der Fixpunktschlange angeordnet wurden, mit den Fixpunkten in dem Speicher 120 gespeichert werden (das System kann zu irgendeinem Zeitpunkt zusammenbrechen). In einer Ausführungsform kann der Satz von Anderungen, der an dem Speicher 120 vorgenommen wurde, kombiniert werden zu einem unteilbaren Vorgang. Ein unteilbarer Vorgang ist ein Vorgang bzw. eine Operation, die eine Serie von Schritten aufweisen kann, die nicht beendet sind bzw. beendet werden, bis nicht sämtliche Schritte der unteilbaren Operation als erfolgreich abgeschlossen bestätigt wurden. Die unteilbare Operation ermöglicht es, daß alle Schritte in der Operation ungeschehen gemacht werden, wenn irgendeiner der Schritte in der Operation nicht erfolgreich abgeschlossen wird. Der Prozeß des Rückgängigmachens aller Schritte in einer atomaren Operation kann als "Rückabwickeln" der Operation bzw. des Vorganges bezeichnet werden. In dem obigen Beispiel kann, wenn einer aus einer Serie von zwei oder mehr Fixpunkten in einer Fixpunktschlange nicht abgeschlossen wurde, wenn ein zusammengebrochenes System wiederhergestellt wird, das System bis zu einem vorherigen Fixpunktzustand rückabgewickelt werden.
In einer Ausführungsform kann eine API auf Transaktionsbasis vorgesehen sein, um dem Clientsystem 100 zu ermöglichen, Fixpunktanforderungen auszugeben. Unter Verwendung der API kann das Clientsystem 100 dem Speicher mitteilen:

• wenn eine neue Transaktion beginnt
• welche Heap-Seiten gesichert werden müssen,
• wann die Transaktion durchgeführt wird.

Ein SpeicherFixpunkt kann einen oder mehrere der folgenden Zustände haben, die für den Speicher dauerhaft gemacht werden können:

• alle verunreinigten Benutzerseiten seit dem letzten Fixpunkt gesichert
• alle verunreinigten Systemseiten seit dem letzten Fixpunkt gesichert
• Sichern des aktuellen Zustandes interner Struktur (Thread-Kontexte, Zeiger auf Hauptstruktur in dem Heap, wie z.B. Klassen, Konstantenvorrat, etc.), die nicht in dem Heap sind (beispielsweise eine virtuelle Maschine).

In einer Ausführungsform hat das Clientsystem 100 zu einem gegebenen Zeitpunkt möglicherweise nur eine offene Speichertransaktion. Jeder nachfolgende SpeicherFixpunkt kann in einer getrennten Transaktion gekapselt sein. Wenn ein SpeicherFixpunkt ausgegeben wird, muß die Ausführung des Clientsystems 100 möglicherweise für eine möglichst kurze Zeit gestoppt werden, um nicht in dem Heap vorhandene Strukturen der virtuellen Maschine zu sichern. Eine Ausführungsform kann ein Vorabspülen von verunreinigten Seiten bereitstellen, indem sie erlaubt, daß verunreinigte Seiten unabhängig von dem SpeicherFixpunkt mit Fixpunkten versehen werden. Wenn also ein SpeicherFixpunkt ausgegeben wird, können alle Seiten des Heap 108 möglicherweise bereits in dem Speicher 120 gesichert worden (vorgespült) sein. Demnach sind die einzigen Strukturen, die möglicherweise noch gespeichert werden müssen, einige wenige verunreinigte Systemseiten und die nicht zum Heap gehörenden Strukturen der virtuellen Maschine. In einer Ausführungsform kann der Speicher verifizieren, daß alle Zustände korrekt in den Speicher 120 geschrieben wurden, wenn die Fixpunkttransaktion durchgeführt wurde. Wenn einer oder mehrere Schreibvorgänge fehlgeschlagen sind oder nicht abgeschlossen wurden, kann der Speicher die Transaktion abbrechen und eine Rückabwicklung bis zu dem letzten abgeschlossenen Fixpunkt vornehmen. In einer Ausführungsform kann das Clientsystem, wenn der Fixpunkt fehlschlägt, jedoch das Clientsystem 100 immer noch läuft, mit Einschränkungen fortfahren, wie z.B. so, daß kein weiterer Seitenwechsel erlaubt ist, und auch den Benutzer warnen, daß die Speicherung verlorengegangen ist. In einer anderen Ausführungsform kann das Clientsystem 100 gestoppt werden, wenn der Fixpunkt fehlschlägt. In einer Ausführungsform kann eine Fixpunkterstellende API auf Anwendungsniveau vorgesehen werden, um die Anwendung 104 zu informieren, daß das Fixpunkterstellen fehlgeschlagen ist.
Das Clientsystem 100 kann verifizieren, das irgendwelche Veränderungen auf dem Heap oder nicht auf dem Heap korrekt als Teil der Speichertransaktion aufgezeichnet wurden. Der Speicher kann verifizieren, daß alle Änderungen dauerhaft gemacht worden sind (in den nichtflüchtigen Speicher geschrieben wurden, wie z.B. auf eine Festplatte oder einen Flash-Speicher) und daß der Speicher in einem konsistenten Zustand hinterlassen wurde.
Das Clientsystem 100 beruht möglicherweise darauf, daß der Speicher ACID-Eigenschaften der Transaktion garantiert. ACID ist das Akronym, welches verwendet wird, um die folgenden Eigenschaften einer Transaktion zu beschreiben:

• ATOMICITY (Unteilbarkeit): Eine Transaktion sollte vollständig erledigt oder vollständig unerledigt sein. Im Falle eines Versagens sollten alle Vorgänge und Pro zeduren rückgängig gemacht werden und alle Daten sollten bis zu ihrem vorherigen Zustand rückabgewickelt werden.
• CONSISTENCY (Konsistenz): Eine Transaktion sollte ein System von einem konsistenten Zustand zu einem anderen konsistenten Zustand überführen.
• ISOLATION: Jede Transaktion sollte unabhängig von anderen Transaktionen geschehen, die gleichzeitig erfolgen.
• DURABILITY (Dauerhaftigkeit): Abgeschlossene Transaktionen sollten dauerhaft bleiben, selbst bei Ausfällen des Systems.

In einer Ausführungsform kann der Speicher womöglich nur einen Fixpunkt pro Anwendung halten (den letzten erfolgreichen durchgeführten Fixpunkt). In einer anderen Ausführungsform könnte der Speicher einen oder mehrere Fixpunkte pro Anwendung behalten und das Clientsystem 100 kann auswählen, welcher Fixpunkt verwendet werden soll, wenn eine Anwendung erneut gestartet wird.
Da jeder Anwendungsspeicher in einem anderen virtuellen Heapabschnitt des dauerhaften Speichers 120 aufbewahrt wird, kann der Heapabschnitt der aktuellen Anwendung für einen Fixpunkt "berührt" werden, während andere Abschnitte der Anwendung unberührt bleiben.
In einer Ausführungsform kann eine Benutzerschnittstelle (UI) der Speicherverwaltung vorgesehen sein und kann das Entfernen eines beschädigten virtuellen Heap einer Anwendung ermöglichen.
Wann soll ein SpeicherFixpunkt ausgeführt werden?
In einer Ausführungsform kann, um die Zustände des Heap 108 und des Clientsystems 100 sehr eng mit dem Speicher 120 synchronisiert zu halten, ein SpeicherFixpunkt jedes Mal dann ausgegeben werden, wenn eine Veränderung vorgenommen wird. Diese Ausführungsform ist aber möglicherweise nicht sehr praktisch aufgrund der hohen Dichte von SpeicherFixpunkten, welche die Leistungsfähigkeit herabsetzen können. Um eine Herabsetzung der Leistungsfähigkeit zu vermeiden, könnten der Heap 108 und das Clientsystem 100 mit dem Zustand des Speichers 120 lose synchronisiert sein und SpeicherFixpunkte sollten nur unter bestimmten Bedingungen erstellt bzw. ausgegeben werden. Die folgenden sind Beispiele von Bedingungen, die verwendet werden könnten bei der Entscheidung, wann ein SpeicherFixpunkt ausgegeben werden sollte:

• Da das Clientsystem 100 unterbrochen werden kann, um einen SpeicherFixpunkt auszuführen, kann ein Zeitpunkt ausgewählt werden, um den Fixpunkt auszuführen, der möglicherweise den geringsten Betrag an Zusatzlast erzeugt. Wenn beispielsweise ein Clientsystem ein Threadumschalten oder eine Synchronisation ausführt, so kann eine Überprüfung vorgenommen werden, ob festzustellen, ob ein Fixpunkt ausgeführt werden muß. Das Fixpunkterstellen kann asynchron durchgeführt werden, so daß die Zusatzlast in Bezug auf die Ausgabe der Anforderung und nicht in Bezug auf das Ausführen der Anforderung definiert werden sollte.
• Die Anzahl von Seiten, die seit dem letzten ausgeführten Fixpunkt geschrieben wurden, kann berücksichtigt werden. Wenn viele Seiten aktualisiert wurden, sollten die Änderungen sobald wie möglich ausgeführt werden.
• Die Geschwindigkeit, mit welcher ein TransaktionsFixpunkt in den Speicher ausgeführt werden kann, sollte berücksichtigt werden. Wenn Speichervorgänge langsam sind, muß die Anzahl von Fixpunkten möglicherweise begrenzt werden. Puffern ist möglicherweise keine Option in einer begrenzten Speicherumgebung.
• Ein Fixpunkt kann nach einer Abfallsammlung durchgeführt werden, da aufgrund von Objektsammlungen und einer Heapkompaktierung viele Seiten verändert worden sein können.
• Die Zeit seit dem Auftreten des letzten Fixpunktes kann berücksichtigt werden. Beispielsweise kann eine Anwendung berechnungsintensiv sein und nur eine kleine Anzahl von Seiten berühren. Um den Berechnungszustand zu sichern, kann ein Fixpunkt (eine Fixpunkterstellung) ausgelöst werden nachdem eine Maximalzeit verstrichen ist, wenn keine der vorherigen Bedingungen aufgetreten ist.
• Wann immer die Anwendung ausgesetzt ist und das Clientsystem 100 sich in dem Prozeß des Umschaltens auf eine neue Anwendung befindet, so kann ein Fixpunkt für die ausgesetzte Anwendung erstellt werden.

4 – Eine Berechnungsmethode für Seitenadressen des speicherinternen Heap
4 ist ein Flußdiagramm, welches eine Berechnungsmethode für Seitenadressen des speicherinternen Heap gemäß einer Ausführungsform der Erfindung beschreibt. In einer Ausführungsform kann die Übersetzung eines Seitenaufrufes eines virtuellen Heap in einen Seitenaufruf des speicherinternen Heap die folgenden Schritte aufweisen. In Schritt 300 kann die Speicherseiten-ID bestimmt werden. Ein Beispiel einer Methode zum Bestimmen der Speicherseiten-ID ist: PageID = Sadd – (AppID·HS) << PageS
Dabei ist

Sadd:: die Adresse des Seitenaufrufs des virtuellen Heap, die übersetzt werden muß.
AppID:: die aktuelle Anwendungs-ID, die verwendet wird, um den virtuellen Heap zu speichern. Beispielsweise kann in 2 die Anwendung 104 eine Anwendungs-ID von 1 haben.
HS:: die Größe des virtuellen Heap (kann ein Vielfaches der Größe des speicherinternen Heap sein).
<<:: Schiebeoperator (kann eine Verschiebung nach links oder rechts sein, je nach der Darstellung der Bitreihenfolge in dem System).
PageS:: Bitverschiebung der Seitengröße.

In Schritt 300 kann zunächst die Anwendungs-ID mit der Größe des virtuellen Heap multipliziert werden, um die Basisadresse des virtuellen Heap für die Anwendung zu erhalten. Als zweites kann die Basisadresse des virtuellen Heap von der Seitenaufrufadresse des virtuellen Heap subtrahiert werden, um einen Adressenversatz gegenüber der Basisadresse zu erzeugen. Als drittes kann der Adressenversatz verschoben werden, um die Bits, welche die Adreßinformationen auf den Seiten enthalten, zu entfernen. Wenn beispielsweise eine Seite 256 adressierbare Bytes hat, wird die Adresse möglicherweise um 8 Bit verschoben. In einer Ausführungsform ist das Ergebnis der Verschiebung die Seiten-ID für den Seitenaufruf des virtuellen Heap.
In Schritt 302 kann die Position der Seite in dem Heap aus der Seitentabelle bestimmt werden: HeapPageID = PageTable (PageID)
Wenn beispielsweise, wobei wieder auf 2 Bezug genommen wird, das Ergebnis von Schritt 300 eine virtuelle Heapseite 4 ist, erzeugt das Nachschlagen der Reihe mit der virtuellen Heapseite 4 in Tabelle 122 eine Heapseiten-ID von 1.
Wenn die Seite nicht resident ist, kann ein Seitenfehler ausgegeben werden, um die Seite in den Heap zu bringen. In Schritt 304 kann die speicherinterne Heapadresse berechnet werden. Ein Beispiel einer Methode zum Berechnen der speicherinternen Heapadresse ist: Hadd = HeapPageID·PageS + Sadd & PageMask

PageS:: Seitengröße
Sadd:: die ursprüngliche Seitenaufrufadresse des virtuellen Heap
PageMask:: Bitmaske der Seitengröße
&:: Bitweiser UND-Operator

Als erstes kann die Heapseiten-ID, die in Schritt 302 erzeugt wurde, mit der Seitengröße multipliziert werden, um die Basisadresse der speicherinternen Heapseite zu erzeugen. Die ursprüngliche Seitenaufrufadresse des virtuellen Heap kann dann durch UND mit einer Bitmaske der Seitengröße verknüpft werden, um die Bits zu erzeugen, welche die seiteninterne Adreßinformation enthalten. Die auf der Seite befindliche Adreßinformation kann dann zu der Basisadresse der speicherinternen Heapseite addiert werden, um die speicherinterne Heapadresse zu erzeugen.
5a und 5b – Anwendungsmigration
Die Ausführungsformen eines Prozesses einer Anwendungsmigration, wie in den 5a und 5b dargestellt, sowie anderer, nicht dargestellter Ausführungsformen, kann das Wandern bzw. Migrieren von Java-Anwendungen von einer Maschine zu einer anderen auf einem Netz werk oder Zwischengeräte gewährleisten, wenn zumindest eines der Geräte möglicherweise nicht mit einem Netzwerk verbunden ist. In anderen Ausführungsformen können nicht-reine Java-Anwendungen und/oder nicht-Java-Anwendungen von einer Maschine zu einer anderen auf einem Netzwerk oder Zwischengerät wandern, wenn zumindest eines der Geräte nicht mit einem Netzwerk verbunden ist. Um das Problem der Migration des externen Zustandes einer Anwendung zu handhaben, können wanderungsfähige Anwendungen ein Netzwerkverbindungssystem, wie z.B. Jini, oder ein kompaktes Netzwerkdienstanschlußsystem (CNSCS) für den Zugriff auf Ressourcen, die außerhalb der Anwendungen liegen, und welche als Dienste bezeichnet werden, verwenden. Dienste können lokal sein (auf der Einrichtung, auf welcher die Anwendung läuft), oder entfernt gelegen (auf anderen Einrichtungen, die über das Netzwerk mit dem Gerät bzw. der Einrichtung verbunden sind). Lokale Dienste können Systemressourcen auf der Einrichtung umfassen, innerhalb welcher die Anwendung läuft. Diese lokalen oder entfernt gelegenen Dienste können durch eine Anwendung unter Verwendung eines NSCS oder CNSCS geleast werden. In einer Ausführungsform kann also der externe Zustand der Anwendung durch eine oder mehrere Überlassungen von lokalen und/oder entfernt gelegenen Diensten, einschließlich Systemressourcen, überlassen werden. Andere Ausführungsformen müssen möglicherweise andere Methoden für das Zugreifen auf externe Ressourcen verwenden, welche die Bewahrung des externen Zustandes während der Migration erlauben.
In einer Ausführungsform wird jede Anwendung auf einem System von anderen Anwendungen getrennt und ist damit getrennt von anderen Anwendungen wanderungsfähig. In einer Ausführungsform kann jede Anwendung auf einem System einen speicherinternen Heap haben, der als "physikalischer" Speicher dient, welcher für die aktuelle Ausführung der Anwendung verwendet wird, einen virtuellen Speicher haben, der möglicherweise den gesamten Heap der Anwendung einschließlich zumindest eines Teiles der Laufzeitumgebung der virtuellen Maschine umfaßt, und einen persistenten Heap oder Speicher haben, wo der virtuelle Heap mit Fixpunkten versehen werden kann. In einer Ausführungsform können der virtuelle Heap und der persistente Heap in einem Speicher kombiniert werden (der virtuelle Heap dient möglicherweise als der persistente Heap). In einer anderen Ausführungsform kann der virtuelle Heap mit Fixpunkten in einen getrennten, eindeutig dauerhaften Heap mit Fixpunkten versehen bzw. gespeichert werden. Die Kombination des speicherinternen Heap, des virtuellen Heap und des dauerhaften Speichers kann als "virtueller dauerhafter Speicher" bezeichnet werden. In einer weiteren Ausführungsform ist möglicherweise ausreichend Speicher für den speicherinternen Heap verfügbar, so daß ein virtueller Heap nicht einmal in der Anwendung laufen muß. In dieser Ausführungsform sind möglicherweise nur ein speicherinterner Heap und ein dauerhafter Heap auf dem Speicher für eine Anwendung vorhanden.
Eine Ausführungsform einer Methode zum Wandern bzw. Wandern lassen einer Anwendung kann umfassen:

• Erstellen von Fixpunkten für die Anwendung in ihrem dauerhaften Heap. Zusätzlich können alle aktuellen Überlassungen von externen Diensten und/oder Ressourcen erloschen sein.
• Verpacken des dauerhaften Zustandes der Anwendung in dem dauerhaften Heap und Senden des dauerhaften Heap für die Anwendung an den Knoten, an den die Anwendung wandern soll. In einer Ausführungsform wird ein Transaktionsmechanismus verwendet, wobei der gesamte dauerhafte Zustand der Anwendung automatisch als eine "Transaktion" kopiert werden kann und als migriert ausgeführt werden kann, sowohl auf den sendenden als auch auf den empfangenden Knoten.
• Wiederherstellung des Zustandes der Anwendung in einem neuen persistenten Heap (kann ein virtueller persistenter Heap sein) auf dem Knoten, zu welchem die Anwendung gewandert ist.
• Wiederherstellen der Überlassungen von externen Diensten und/oder Ressourcen für die Anwendung.
• Wiederaufnehmen der Ausführung der Anwendung in dem persistenten Heap auf dem Knoten, zu welchem sie migriert ist.

In einer Ausführungsform kann, da Prozesse, welche von einem Knoten weg migrieren und nach einer kleinen Zustandsänderung auf dem Knoten, wohin sie migriert sind, wieder zurück migrieren (z.B. mit einer aktualisierten Seite eines Dokumentes), ein Versionsmechanismus verwendet werden, durch welchen Knoten, auf welchen eine Anwendung einmal existiert hatte, einen vorhergehenden Zustand in einem Cache aufnehmen und damit das Senden eines Zustandes, der sich nicht verändert hat, über das Netzwerk vermeiden kann.
Information über die aktuellen Überlassungen der Anwendung können auch verpackt und an den neuen Knoten gesendet werden, wohin die Anwendung wandern soll. Die Information kann verwendet werden beim Wiederbereitstellen der Überlassungen auf dem neuen Knoten. In einer Ausführungsform kann die Überlassungsinformation in einem Nachrichtenendpunkt oder einer Gatestruktur aufbewahrt bzw. gehalten werden.
Zusätzlich kann eine Benutzerschnittstelle (UI) vorgesehen sein, um AnwendungsFixpunkte zu verwalten. Funktionen der UI, welche der Benutzer durchführen kann, können, ohne darauf beschränkt zu sein, die folgenden umfassen:

• Browsen des Speichers.
• Auswählen eines AnwendungsFixpunktes für einen erneuten Start.
• Aussetzen der aktuellen Anwendung.
• Entfernen eines AnwendungsFixpunktes.

5a ist ein Blockdiagramm, welches eine Ausführungsform eines Anwendungswanderungsprozesses veranschaulicht, in welchem die ursprüngliche Wanderung 104a und die gewanderte Anwendung 104b möglicherweise denselben virtuellen Heap 110 in dem dauerhaften Speicher 120 verwenden. In 5a wird der speicherinterne Heap 108 für die Anwendung 104a, die auf dem Clientsystem 100 abläuft, mit einem Fixpunkt in dem dauerhaften Speicher 120 gespeichert. Das Fixpunkterstellen kann als eine unteilbare Transaktion durchgeführt werden. Der Speicherfixpunkt kann eine oder mehrere der folgenden Zustände umfassen, die in dem Speicher dauerhaft gemacht werden können:

• Alle verunreinigten Benutzerseiten seit Beginn der Transaktion.
• Alle verunreinigten Systemseiten seit Beginn der Transaktion.
• Der aktuelle Zustand der internen Strukturen (Threadkontexte, Zeiger auf die Hauptstruktur in dem Heap, wie z.B. Klassen, Konstantenvorrat, etc.), die nicht im Heap sind (z.B. die virtuelle Maschine).

Alle aktuellen Überlassungen von externen Diensten (beispielsweise Dienste, die über einen NSCS, wie z.B. Jini oder einen CNSCS überlassen wurden), können erloschen sein. In einer Ausführungsform kann ein Erlöschen der aktuellen Überlassungen vor der Migration erforderlich sein. In einer Ausführungsform ist das Erlöschen aktueller Überlassungen vor dem Fixpunkterstellen der Anwendung nicht erforderlich.
Der in einem Fixpunkt dauerhafte Zustand der Anwendung 104, der in dem dauerhaften Speicher 120 gespeichert ist, einschließlich Benutzerseiten, Systemseiten und des aktuellen Zustandes von nicht-Heap-Strukturen, wird verpackt und an das Clientsystem 130 gesendet, wo die Anwendung 104a hinwandern soll. Inn diesem Schritt kann ein Transaktionmechanismus verwendet werden, in welchem der vollständige persistente Zustand eines Prozesses automatisch kopiert und als migriert sowohl auf dem sendenden als auch auf dem empfangenden Clientsystem ausgeführt wird. In einer Ausführungsform kann, da erwartet werden kann, daß Prozesse, die von einem Clientsystem weg migrieren, nach nur einer relativ kleinen Zustandsänderung auf dem Clientsystem, zu welchem sie migriert sind (wo sie z.B. eine Seite eines Dokumentes aktualisiert haben), zurückmigrieren, ein Versionsmechanismus verwendet werden, durch welchen Knoten, auf welchen eine Anwendung einmal existiert hat, frühere Zustände in einem Cache aufnehmen können und das Senden eines Zustandes, der sich nicht verändert hat, über das Netzwerk vermeiden können.
Der verpackte und gesendete Zustand wird empfangen und auf dem Clientsystem 100 wieder zusammengesetzt und die Anwendung 104b nimmt den Ablauf auf dem neuen Clientsystem wieder auf. Ein neuer speicherinterner Heap 108b kann für die Anwendung 104b zugeordnet werden, einschließlich der mit Fixpunkten versehenen Benutzer- und Systemseiten. Der aktuelle Zustand von nicht-Heap-Strukturen auf dem Clientsystem 130 kann aus dem empfangenen Fixpunktzustand eingestellt werden. Erforderliche Überlassungen von Diensten können für die Anwendung wiederhergestellt werden. Die Anwendung 104b kann dann den Ablauf in dem Heap 108b auf dem Clientsystem 130 wieder aufnehmen, wohin sie migriert ist. Die Anwendung 104b kann fortfahren, den persistenten Speicher 120 für ihren virtuellen Heap weiterhin zu verwenden, oder kann einen neuen virtuellen Heap in einem anderen persistenten Speicher auf dem Clientsystem 130 bereitstellen oder auf einem anderen Server, der persistenten Speicherraum auf dem Netzwerk bereitstellt.
5b veranschaulicht eine Ausführungsform, in welcher ein Client 100 einen persistenten Speicher 120a aufweist, der durch die Anwendung 104a verwendet wird, um den virtuellen Heap 110a zu speichern. Wenn die Anwendung 104a zu dem Client 130 wandert, so kann ein Fixpunktzustand der Anwendung 104a an den Client 130 gesendet werden. Bei dem Client 130 kann ein neuer virtueller Heap 104b in dem persistenten Speicher 120b bereitgestellt werden, es kann ein neuer speicherinterner Heap 108b bereitgestellt werden und die Anwendung 104b kann ihre Ausführung auf den Client 130 aus dem Fixpunktzustand der Anwendung 104a heraus wieder aufnehmen.
6 – Ein Verfahren zum Migrieren einer Anwendung
6 ist ein Flußdiagramm, welches ein Verfahren zum Migrieren von Prozessen, einschließlich Anwendungen, von einem Clientsystem zu einem anderen gemäß einer Ausführungsform der Erfindung zeigt. Clientsysteme können "reale" Systeme sein, wie z.B. die Windows 9x/NT-Systeme oder virtuelle Maschinen, wie z.B. die virtuellen Java-Maschinen, die oben auf anderen Systemen laufen. In einer Ausführungsform kann jede Anwendung von anderen Anwendungen auf dem System unabhängig sein und kann demnach getrennt von anderen Anwendungen migrationsfähig sein. In einer Ausführungsform hat jede Anwendung auf einem bestimmten Clientsystem einen speicherinternen Heap, wo sie ausgeführt wird, und einen persistenten Heap, auf welchen sie mit Fixpunkten aufgenommen werden kann, bevor sie wandert bzw. überführt wird.
In Schritt 320 wird die Anwendung 104, die auf dem Clientsystem 100 mit einem Fixpunkt in ihrem dauerhaften Heap 108 in dem dauerhaften Speicher 120 aufgenommen. Der Speicherfixpunkt kann einen oder mehrere der folgenden Zustände umfassen, die in dem Speicher dauerhaft gemacht werden können:

• Alle verunreinigten Benutzerseiten seit Beginn der Transaktion.
• Alle verunreinigten Systemseiten seit Beginn der Transaktion.
• Aktueller Zustand der internen Strukturen (Thread-Kontexte, Zeiger auf Hauptstruktur in dem Heap, wie z.B. Klassen, Konstantenvorrat, etc.), die nicht in dem Heap sind (beispielsweise die virtuelle Maschine).

Eine "Benutzerseite" umfaßt anwendungsspezifische Daten oder ausführbaren Code. Eine "System"-Seite umfaßt Betriebssystem- oder virtuelle Maschinendaten oder ausführbaren Code, der nicht anwendungsspezifisch ist.
In Schritt 322 können aktuelle Überlassungen von Diensten (beispielsweise Dienste, die über einen NSCS, wie z.B. Jini, oder einen CNSCS geleast wurden) auf dem Clientsystem 100 erloschen sein. In einer Ausführungsform müssen alle aktuellen Überlassungen vor der Migration erloschen sein.
In Schritt 324 wird der zuletzt mit Fixpunkten versehene, dauerhafte Zustand der Anwendung 104 in dem dauerhaften Speicher 120 verpackt und an das Clientsystem 130 gesendet, wohin die Anwendung 104 migrieren soll. In Schritt 326 wird der verpackte, mit Fixpunkten verse hene bzw. definierte Zustand der Anwendung 104 auf dem Clientsystem 130 empfangen. In einer Ausführungsform kann ein Transaktionsmechanismus verwendet werden, wobei der gesamte dauerhafte Zustand eines Prozesses in Schritt 328 unteilbar kopiert und so als migriert ausgeführt wird, sowohl auf dem sendenden als auch auf dem empfangenden Clientsystem.
In Schritt 330 wird der empfangene, verpackte Zustand auf dem Clientsystem 130 wieder aufgebaut, wohin die Anwendung 104 migriert ist. Erforderliche Überlassungen lokaler und/oder entfernter Dienste können für die Anwendung 104 in Schritt 332 wiederhergestellt werden. In einer Ausführungsform können eine oder mehrere der in Schritt 322 erloschenen Überlassungen wiederhergestellt werden. In einer Ausführungsform umfaßt der empfangene, verpackte Zustand Information, welche die eine oder mehreren Überlassungen, die in Schritt 322 erloschen sind, beschreibt, und diese Information über die Überlassungen kann in Schritt 332 verwendet werden, um die Überlassungen wiederherzustellen. In einer Ausführungsform können die wiederhergestellten Überlassungen Überlassungen von Systemressourcen auf dem Gerät umfassen, auf welches die Anwendung migriert ist. In Schritt 334 kann die Anwendung 104 dann unter Verwendung des Heap 108 auf dem Clientsystem 130, wohin sie migriert ist, ihren Ablauf wieder aufnehmen. Die migrierte Anwendung 104 kann weiterhin den virtuellen Heap 110 verwenden, der durch die Anwendung 104 auf dem Clientsystem 100 vor der Migration verwendet wurde, wie in 5a dargestellt wird. Alternativ kann ein neuer virtueller Heap 110 für die Anwendung 104 auf dem Clientsystem 130 bereitgestellt werden, wie es in 5b dargestellt ist.
7 – Architektur eines virtuellen persistenten Heap unter Verwendung von Cachezeilen
Ein Merkmal des virtuellen, persistenten Heap ist die Methode, die verwendet wird, um Teile des virtuellen persistenten Heap in dem "physikalischen" speicherinternen Heap als Cache aufzunehmen. Der virtuelle persistente Heap kann einen Cachemechanismus aufweisen, der bei kleinen Verbraucher- und Anwendungsgeräte wirksam ist, die typischerweise nur einen kleinen Speicherumfang haben und die möglicherweise Flasheinrichtungen als dauerhaften Speicher verwenden. Die Cachestrategie kann ein geringeres Maß an Cachespeicherung erreichen und kann die Lokalität zwischen Elementen des virtuellen persistenten Heap, die in den physikalischen Heap (als Cache) gepuffert bzw. zwischengespeichert werden, verbessern, und vermindert dadurch die Zusatzlast durch die Cacheaufnahme. Die 2 bis 5 veranschaulichen Ausführungsformen, die eine "Seite" als Niveau der Granularität des virtuellen, persistenten Heap-Cache-Mechanismus verwenden.
7 ist ein Blockdiagramm, das eine Ausführungsform einer Architektur eines virtuellen persistenten Heap zeigt, die der Ausführungsform, die in 2 dargestellt ist, weitgehend ähnlich ist. Die Anwendung 104 kann in dem Clientsystem 100 ablaufen. Die Anwendung 104 kann einen speicherinternen Heap 108 verwenden. Der dauerhafte Speicher 120 kann auf einem Server im Netzwerk liegen, auf welchen das Clientsystem 100 Zugriff hat, oder kann alternativ in einem lokalen, nicht-flüchtigen Speicher auf dem System liegen, auf welchem die Anwendung 104 abläuft. Die Cachetabelle 122 kann auf demselben System liegen wie die Anwendung 104 oder kann alternativ auch auf einem anderen System in dem Netzwerk liegen.
Die in 7 dargestellte Ausführungsform umfaßt einen Cachemechanismus, in welchem der virtuelle, persistente Heap in Cachezeilen aufgeteilt ist. Eine Cachezeile ist der kleinste Betrag an Speicherraum des virtuellen persistenten Heap, der auf einmal geladen oder ausgespült werden kann. Cacheaufnahme und Cacheausgabeoperationen werden verwendet, um Cachezeilen in den Heap zu laden oder verunreinigte Cachezeilen in den Speicher auszuspülen. Im allgemeinen umfaßt die Definition einer "Seite", wie sie in den 2 bis 5 verwendet wird, eine Cachezeile. Mit anderen Worten, eine Cachezeile hat die Größe einer Seite. In anderen Ausführungsformen kann eine Objektgranularität in einem virtuellen persistenten Heap verwendet werden. In diesen Ausführungsformen können Cacheeingabe- und Cacheausgabeoperationen mit Objekten durchgeführt werden, welche durch die Anwendung erzeugt werden können.
Ein Niveau der Objektlokalität in jeder Cachezeile kann erreicht werden, um den Heap-Abfall durch Verwenden von Objekt-Cacheschulen und einem Generationsabfallsammler zu reduzieren, wie nachstehend beschrieben wird. Unterschiedliche Cachezeilengrößen können für unterschiedliche Bereiche in dem Heap verwendet werden. Cachezeilen können einen natürlich Pfad für das Überführen des virtuellen persistenten Heap zu Architekturen einer Speicherverwaltungseinheit (MMU) auf Cachebasis bereitstellen und sie können eine Adreßübersetzung aus dem virtuellen persistenten Heap in den in Hardware auszuführenden Heap ermöglichen.
In einer Ausführungsform können alle Heapaufrufe in einem Adreßraum gehalten werden (der Adreßraum des virtuellen persistenten Heap). Die Adreßübersetzung wird deshalb vereinfacht und erfordert möglicherweise kein Einbeziehen ("Swizzling") von virtuellen Aufrufen in Aufrufe des speicherinternen Heap, wenn Objekte in dem Heap manipuliert bzw. gehandhabt werden. In einer Ausführungsform kann das Vorhandensein eines einzelnen Adreßraumes es ermöglichen, daß ein einzelner Abfallsammler auf dem Raum bzw. Speicherraum des virtuellen persistenten Heap läuft. Wenn ein einzelner Adreßraum nicht verwendet wird, können zwei oder mehr Abfallsammler erforderlich sein, beispielsweise einer, der auf dem virtuellen persistenten Heap läuft und einer, der auf dem speicherinternen Heap läuft.
Der Begriff "virtueller persistenter Heap" kann verwendet werden, um das gesamte Bild des virtuellen Heap zu bezeichnen, das in dem dauerhaften Speicher gesichert wird. Die Begriffe speicherinterner Heap oder Heap können verwendet werden, um sich auf den Teil des virtuellen Speichers zu beziehen, der aktuell im Speicher cachegespeichert ist. Der Begriff "Cachezeile" kann verwendet werden, um die kleinste Granularität der Cacheingabe und Cacheausgabe zu bezeichnen. Eine Cachezeile entspricht der kleinsten Menge an Daten, die auf einmal in den speicherinternen Heap geladen oder aus diesem ausgespült werden kann. Der speicherinterne Heap und der virtuelle persistente Heap können in Cachezeilen fester Größe aufgeteilt sein oder alternativ können die Heaps in Gruppen von Cachezeilen mit unterschiedlichen Cachezeilengrößen aufgeteilt sein. Die Größe des virtuellen persistenten Heap kann ein Mehrfaches der maximalen Größe des speicherinternen Heap betragen und es kann ein Schema auf Offsetbasis, wie z.B. das in 4 dargestellte, verwendet werden, um Adressen des virtuellen persistenten Heap in Adressen des speicherinternen Heap umzuwandeln.
In einer Ausführungsform können Aufrufe in dem virtuellen persistenten Heap und der Struktur des speicherinternen Heap als virtuelle, persistente Heapadressen aufbewahrt werden. Es gibt möglicherweise keine Aktualisierungen von physikalischen Heapaufrufen, wenn Heapaufrufe gehandhabt werden. Die Adreßübersetzung aus dem Adreßraum des virtuellen persistenten Heap an den Ort des speicherinternen Heap kann unter Verwendung eines Cachetabelleneintrags erfolgen.
In einem System auf Cachezeilenbasis kann die Größe der Cachezeilen erhöht werden, um die Größe der Cachetabelle zu reduzieren. Das Vergrößern der Cachezeilengröße kann möglicherweise das Gruppieren mehrerer Objekte in eine einzelne Cachezeile erlauben. In diesem Fall kann ein einzelner Cachetabelleneintrag die Rolle von mehreren Objekthandhabungseinträgen spielen (eine Handhabung für jedes Objekt in der Cachezeile). Das Gruppieren von Objekten in einen einzelnen Cachetabelleneintrag kann die Reduzierung der Speicherbasis ermöglichen, die für eine Handhabungstabelle erforderlich ist, weil es weniger Handhabungen gibt. Das Aktualisieren eines einzelnen Objektes in der Cachezeile kann das Schreiben der gesamten Cachezeile (alle Objekte in der Cachezeile) erfordern. Alternativ ermöglicht das Reduzieren der Cachezeilengröße, daß nur wenige Objekte in einer Cachezeile gespeichert werden, wodurch die Granularität der Cachespeicherung reduziert wird. Dieser Ansatz vergrößert möglicherweise die Cachetabellengröße. Die Cachezeilengröße kann dementsprechend auf der Basis der Speichereinschränkungen des Gerätes, auf welchem das cachezeilenbasierte System implementiert wird, eingestellt werden.
Bei jedem virtuellen persistenten Heapaufruf (Lesen oder Schreiben) können Lese-/Schreib-Barrieren verwendet werden, um die Gültigkeit der Adresse zu verifizieren (d.h. um zu überprüfen, ob die betreffende Cachezeile in dem Heap liegt), und sie in die aktuelle Heapposition zu übersetzen.
In einer Ausführungsform können Objekte in dem virtuellen persistenten Heap Aufrufe von anderen Objekten über eine gültige oder eine ungültige Adresse aufbewahren. Eine gültige Adresse kann bedeuten, daß die betreffende Adresse in dem speicherinternen Heap liegt. Eine ungültige Adresse kann bedeuten, daß die betreffende Adresse nicht in dem speicherinternen Heap liegt.
Cachespeicheraspekte für Flasheinrichtungen
Unter Verwendung der Cachezeilenadressierung können Lesevorgänge mit einer sehr kleinen Granularität (beispielsweise 2 Bytes) erfolgen. Das Einbringen einer Cachezeile anstelle eines einzelnen Objektes in den speicherinternen Heap bedeutet, daß mehr Objekte in den Heap gebracht werden können, als erforderlich ist. Beispielsweise kann eine Cachezeile zwei Objekte enthalten, wobei möglicherweise nur eines von der Anwendung benötigt wird. Das Cachespeichern der Cachezeilen in dem speicherinternen Heap kann zu einer Cachespeicherung sowohl des erforderlichen Objektes als auch des nicht-erforderlichen Objektes führen. Dies kann noch erschwert werden, wenn es nur eine schlechte Objektlokalität gibt (d.h., wenn nicht miteinander zusammenhängende Objekte sich in derselben Cachezeile befinden). Wenn die Cachezeile zu groß ist, werden zahlreiche Objekte, die eingelesen wurden, möglicherweise nie aufgerufen. Cachezeilen verschwenden möglicherweise auch Heapraum, wenn die Zeilen nicht voll sind. Beispielsweise könnte eine durchschnittliche Objektgröße für eine Anwendung 50 Byte sein und eine Cachezeilengröße könnte 4 Kilobyte sein. Wenn in einer 4 Kbyte-Cachezeile in diesem Beispiel 40 Objekte liegen, könnte in etwa die Hälfte der Cachezeilen unbenutzt bleiben.
Flashspeicherschreibvorgänge sind typischerweise destruktiv und sie werden deshalb vorzugsweise minimal gemacht. Flasheinrichtungen können relativ große Blockschreibvorgänge (beispielsweise 128 Kbyte) verwenden. In einer Ausführungsform kann die Cachezeilengröße für eine optimale Leistungsfähigkeit ein Mehrfaches des Flashblockschreibgröße sein. In einer Ausführungsform kann die Cachezeilengröße gleich der Blockschreibgröße sein. In einer Ausführungsform kann eine Cachezeilenspülung die gesamte Zeile (alle Objekte in der Zeile) schreiben.
Aus dem obigen ergibt sich offensichtlich, daß Cachezeilen für Lesevorgänge klein sein können und Cachezeilen für Schreibvorgänge groß sein können. Beispielsweise können Cachezeilen beim Lesen 4 Kilobyte betragen und Cacheschreibzeilen können 128 Kbytes betragen. Um beide Erfordernisse zu erfüllen, müssen unterschiedliche Schulbereiche in dem Heap verwendet werden, um Objekte mit unterschiedlichen Spülstrategien zu kombinieren. Zerstreu-/Sammelvorgänge können ebenfalls verwendet werden, um verunreinigte Objekte in Cache-I/O-Puffer kombiniert zu speichern, so daß nur aktualisierte Objekte geschrieben werden, was größere Schreibumfänge erlaubt.
Die Cachespeicherung kann ein einfaches Schema bereitstellen, Daten zwischen dem Speicher und dem speicherinternen Heap zu laden und zu spülen. In einer Ausführungsform kann eine Adreßübersetzung auf Basis von Cachetabellen und Offset verwendet werden, um Aufrufe in dem virtuellen persistenten Heap in speicherinterne Heap-Aufrufe umzuwandeln. Aufeinanderfolgende Cachespeicherungs- und Abfallsammel-Kompaktierungszyklen können die räumliche Lokalität verbessern, so daß Cachezeilen verwandte bzw. in Beziehung stehende Objekte enthalten können. Dies kann dazu beitragen, den Heapabfall zu reduzieren und die Leistungsfähigkeit aufgrund von weniger Cachespeicherung zu verbessern. Kleinere Cachezeilenbereiche können ebenfalls verwendet werden, um den Heap-Abfall zu reduzieren.
Das Ausspülen in eine Flasheinrichtung kann einen Zerstreu-/Sammel-Schritt umfassen, um verunreinigte Objekte kombiniert in vorab zugeordneten Cache-I/O-Puffern zu kombinieren, so daß eine minimale Anzahl von Schreibvorgängen ausgeführt wird. In einer Ausführungsform werden nur verunreinigte Objekte geschrieben, um die Lebensdauer des Flash zu erhöhen. Dies kann kombiniert werden mit einer Speicherung auf Protokollbasis und Unteilbarkeit für Speichertransaktionen, um die Konsistenz des Bildes des virtuellen persistenten Heap, der in dem persistenten Gerät gespeichert ist, aufrechtzuerhalten.
Das Verwenden von Cachezeilen und einer Cachetabelle ist möglicherweise eine Ver besserung gegenüber der Verwendung einer Tabelle über residente Objekte (ROT), um Objekte, die in dem Heap residieren, weiterhin zu verfolgen. Eine ROT besetzt einen relativ großen Betrag an Heapraum (ein Eintrag für jedes residente Objekte gegenüber einem Eintrag für jede Cachezeile). Der Cachezeilenansatz verwendet möglicherweise signifikant weniger Heapraum als ein Ansatz, der Objektgranularität verwendet.
In einer Ausführungsform können Cachezeilen "gefärbt" werden, indem man die Bezeichnung von Systemen und Benutzerzeilen hinzufügt. Beispielsweise können Kernklassen der virtuellen Maschine, die durch die primäre Ladeeinrichtung geladen werden, welche von allen Anwendungen gemeinsam verwendet wird, einem Systemcachebereich zugeordnet werden. Zusätzlich können Nur-Lese-Objekte in einem Nur-Lese-Bereich angeordnet werden.
Das Folgende sind Beispiele von Typen von Vorgängen, die mit einer virtuellen, persistenten Heap-Cache-Zeile auftreten können:

• Cachetreffer: Es erfolgt ein Aufruf einer gültigen Cachezeile in dem Adreßraum des virtuellen Heap der Anwendung. Der speicherinterne Heap enthält aktuell die Cachezeile. Die Cachetabelle enthält die Zuordnung der Cachezeile in dem Heap.
• Cachefehlgriff: Es erfolgt ein Aufruf auf eine ungültige Cachezeile in dem Adreßraum des virtuellen Heap. Der speicherinterne Heap enthält aktuell nicht die Cachezeile. Ein Cachefehlgriff tritt auf. Die Cachezeile muß aus dem virtuellen Heap in den Speicher an eine freie Heapstelle in dem speicherinternen Heap geladen werden.
• Cachespülen: Die verunreinigte Cachezeile wurde in der Spülschlange angeordnet. Die Schreibsperre für die Cachezeile wird beschafft, so daß keine weiteren Schreibvorgänge erfolgen können, bis die Zeile in den Speicher ausgespült ist. Wenn das Spülen abgeschlossen ist, wird die Schreibsperre freigegeben.
• Cacheausstoßung: Die Cachezeile wird aus dem Heap ausgestoßen. Wenn die Cachezeile verunreinigt ist, muß der Cache in den Speicher ausgespült werden. Wenn dieses abgeschlossen ist, kann der entsprechende Cachetabelleneintrag freigegeben werden.

Um die Bereitstellung einer effizienten Adreßübersetzung zu unterstützen, kann die Größe des virtuellen Heap der Anwendung (d.h. Kernel und alle Benutzerinformationen) ein festgelegtes Vielfaches der Größe des speicherinternen Heap sein. Jeder virtuelle persistente Heap der Anwendung kann bei einem Versatz bzw. Offset eines Mehrfachen der Heapgröße in dem Speicher gespeichert werden. Die Adreßübersetzung umfaßt möglicherweise das Subtrahieren eines Vielfachen einer festen Heapgröße. Die Cachetabelle kann das Zuordnen der Cachezeile des virtuellen persistenten Heap an eine Stelle des speicherinternen Heap aufbewahren bzw. festhalten.
Der obige Cachespeicher-Ansatz kann eine Cachetabellenumlenkung zu jedem Objektaufruf hinzufügen. Die Cachetabellenumlenkung ist der Objekthandhabungsumlenkung weitge hend ähnlich. Beispielsweise ist die Einstellung einer Cachezeile, so daß sie ein einzelnes Objekte enthält, ähnlich einer traditionellen virtuellen Maschine mit einer Handhabung pro Objekt. Das Vergrößern der Cachezeilengröße kann das Laden und Spülen mehrerer Objekte in einem einzelnen Cachespeichervorgang ermöglichen. Ein Cachetabelleneintrag kann die Rolle von mehrfachen Objekthandhabungseinträgen spielen (eine Handhabung für jedes Objekt in der Zeile). Ein Vorteil der Gruppierung von Objekten in einem einzelnen Cacheeintrag liegt darin, daß die Speicherbasis, die für die Cachetabelle erforderlich ist, reduziert wird (es gibt weniger Handhabungen). Dies ist vorteilhaft für Geräte mit kleinem Speicher. Wenn zu viele Objekte in einer Cachezeile gruppiert werden (was die Cachezeile zu groß macht), so kann das Aktualisieren eines einzelnen Objektes in der Zeile möglicherweise das Ausspülen der gesamten Cachezeile erfordern (alle Objekte in der Zeile). Das Lesen eines einzelnen Objektes kann auch das Laden der gesamten Cachezeile erfordern. Das Verwenden von Cachezeilenhandhabungen anstelle von Objekthandhabungen kann die Fähigkeit bieten, die Implementierung so abzustimmen, daß sie zu dem Speicherbasiserfordernis des ins Auge gefaßten Gerätes paßt. Die Cachezeilengröße bestimmt die Menge an Speicherraum, der für die Cachetabelle erforderlich ist. Größere Speicherumgebungen können kleinere Cachezeilen verwenden. Kleinere Speicherumgebungen können relativ große Cachezeilen verwenden.
Die Cachetabelle 122 kann einen oder mehrere der folgenden Einträge für jede Cachezeile des virtuellen Heap der aktuellen Anwendung erhalten:

• Typ (Benutzer oder System): der Typ wird verwendet, um die Spül- und Fixpunktstrategie auszuwählen, die verwendet wird, um die Cachezeile auszustoßen und in den dauerhaften Speicher 120 zu spülen. Beispielsweise können Cachezeilen in dem Heap 108 festgesetzt werden und nicht ausgestoßen werden.
• Resident (wahr oder falsch – TRUE oder FALSE): Der Resident-Eintrag bewahrt bzw. halt den Residenzzustand der Cachezeile in dem Heap. Wenn er den Wert wahr (TRUE) hat, befindet sich die Cachezeile in dem Heap 108.
• Dirty (wahr oder falsch): wird verwendet, um jegliches Schreiben/Modifikation der Cachezeile zu verfolgen. Wenn dies den Wert wahr hat, so ist die Cachezeile verunreinigt.
• Spülen (wahr oder falsch): wird nur für verunreinigte Zeilen verwendet. Zeigt an, daß sich die Cachezeile in der Fixpunktschlange befindet. Wenn der Wert wahr gilt, befindet sich die Cachezeile in der Liste von Zeilen, die für die Fixpunktaufnahme in den Speicher angefordert wurde.
• Länge: Länge der Cachezeile. Die Länge kann als das Vielfache der minimalen Cachezeilengröße, die unterstützt wird, gehalten werden.
• ID der Cachezeile des Heap: gibt die Position der Cachezeile in dem Heap 108 an.

Nur-Lese/statische Kern/virtuelle Maschinen-Objekte können in festgesetzten und nur zu lesenden Systemcachezeilen angeordnet werden. In einer Ausführungsform werden die Objekte durch den primären Klassenlader mit einem Anhänger (Tag) versehen. Diese Klassen werden typischerweise nicht zweimal geladen. Alle Lese-/Schreib-Kern-/virtuellen Maschinen-Objekte können in dem Cachebereich des Benutzers angeordnet werden. Alle Benutzerobjekte können dem Bereich des Benutzerheap zugewiesen werden.
Eine Cachezeile kann sich in einem der folgenden Zustände befinden:

• Leer: Die Cachezeile ist freigegeben worden oder ist nicht zugeordnet worden und sie ist "leerer Raum" in dem virtuellen persistenten Heap. Eine Ausführungsform kann Speicherraum in dem Speicher 120 vorab zuweisen. In einer anderen Ausführungsform kann möglicherweise kein Speicherraum in dem Speicher 120 vorab zugeordnet werden.
• Resident: Die Cachezeile ist neu zugeordnet worden oder ist aus dem Speicher 120 geladen worden. Es sind bisher noch keine Änderungen vorgenommen worden oder die letzten Veränderungen sind in den Speicher 120 ausgespült worden. Die Kopie in dem Heap 108 ist mit der Kopie in dem Speicher 120 synchronisiert.
• Verunreinigt (dirty): Ein Schreiben in die Cachezeile ist durchgeführt worden und die Veränderungen sind noch nicht in den Speicher 120 zurückgeschrieben worden. Es ist noch keine Anforderung über das Spülen der Cachezeile ergangen.
• Warten auf Spülen: Die Cachezeile befindet sich in der Spülschlange. Die Cachezeile ist aktuell schreibgesperrt, kein weiteres Schreiben kann erfolgen bis die Zeile gespült worden ist.
• Persistent: Die Cachezeile ist ausgestoßen worden. Die Zeile liegt nicht in dem speicherinternen Heap 108.

8 – Berechnung der Cachezeilenadresse in dem speicherinternen Heap
8 ist ein Flußdiagramm, welches eine Ausführungsform eines Verfahrens zum Übersetzen von Cachezeilenaufrufen des virtuellen Heap in Cachezeilenaufrufe des speicherinternen Heap veranschaulicht. In Schritt 340 kann die Cachezeilen-ID des virtuellen persistenten Heap bestimmt werden. Die folgende Funktion kann verwendet werden: CacheID = Sadd (AppID·HS) << CacheLineS

Sadd:: Die zu übersetzende Aufrufadresse der Cachezeile des virtuellen Heap.
AppID:: Die aktuelle Anwendungs-ID, die verwendet wird, um den virtuellen persistenten Heap auszuwählen. Beispielsweise kann in 7 die Anwendung 104 eine Anwendungs-ID von 1 haben.
HS:: Die virtuelle Heapgröße (kann ein Vielfaches der Größe des speicherinternen Heap sein).
<<:: Bildschiebeoperator nach links (kann eine Verschiebung nach links oder rechts sein, je nach der Bitordnungsdarstellung in dem System).
CacheLineS:: Bitverschiebung der Cachezeile.

In Schritt 340 wird als Erstes die Anwendungs-ID mit der virtuellen Heapgröße multipliziert, um die Basisadresse des virtuellen Heap für die Anwendung zu erhalten. Als Zweites kann die Basisadresse des virtuellen Heap von der Aufrufadresse der Cachezeile des virtuellen Heap abgezogen werden, um einen Adressenversatz von der Basisadresse zu erzeugen. Als Drittes kann der Adressenversatz verschoben werden, um die Bits, welche die Adreßinformation der Cachezeile des speicherinternen Heap enthalten, zu entfernen. Wenn beispielsweise eine Cachezeile 256 adressierbare Bytes aufweist, so kann die Adresse um 8 Bit verschoben werden. Das Ergebnis der Verschiebung ist die Cachezeilen-ID für den Aufruf der Cachezeile des virtuellen Heap.
In Schritt 342 kann die Position der Cachezeile in dem speicherinternen Heap über die Cachetabelle festgelegt werden: HeapCacheID = CacheTable (CacheID)
Wenn beispielsweise, wieder unter Bezug auf 7, das Ergebnis von Schritt 340 die Cachezeile 4 des virtuellen Heap ist, erzeugt das Nachschlagen der Reihe mit der Cachezeile 4 des virtuellen Heap in der Cachetabelle 122 eine Cachezeilen-ID des Heap von 1.
Wenn in Schritt 344 die Cachezeile nicht in dem speicherinternen Heap liegt, so kann in Schritt 346 ein Cachefehlgriff ausgegeben werden und die Cachezeile kann in Schritt 348 in den speicherinternen Heap geladen werden. In Schritt 350 kann die speicherinterne Heapadresse berechnet werden. Ein Beispiel einer Methode zum Berechnen der Adresse in dem speicherinternen Heap ist: Hadd = HeapCacheID·CacheLineS + Sadd & CacheLineMask

CachelineS:: Cachezeilengröße
Sadd:: die ursprüngliche Seitenaufrufadresse des virtuellen Heap
CacheLineMask:: Cachezeilenbitmaske
&:: Bitweiser UND-Operator

Als Erstes kann die Cachezeilen-ID des Heap, die in Schritt 342 erzeugt wurde, mit der Cachezeilengröße multipliziert werden, um die Basisadresse der Cachezeile des speicherinternen Heap zu erzeugen. Die ursprüngliche Aufrufadresse der Cachezeile des virtuellen Heap kann dann durch UND mit einer Cachezeilenbitmaske verknüpft werden, um die Bits zu erzeugen, welche die Adreßinformation in der Cachezeile enthalten. Die Adreßinformation in der Cachezeile kann dann zu der Basisadresse der Cachezeile des speicherinternen Heap addiert werden, um die Adresse des speicherinternen Heap zu erzeugen.
9 – Ein Gerät mit virtuellen Heap, Objektschule und Abfallsammler
9 veranschaulicht ein Gerät ähnlich demjenigen, welches in den 1a-1d dargestellt ist. Eine Ausführungsform umfaßt einen Client 101 und einen Speicher 115. Der Client 101 und der Speicher 115 können in einem Gerät vorhanden sein. Alternativ kann der Client 101 in einem Gerät vorhanden sein und der Speicher 115 kann außerhalb des Gerätes angeordnet sein. Das Gerät kann eine Computerplattform mit einem Betriebssystem, wie z.B. ein PC oder ein Laptopcomputer sein, auf dem ein Betriebssystem, wie z.B. Microsoft Windows 9x/NT läuft, oder ein Verbraucher- oder Anwendungsgerät, beispielsweise ein Mobiltelefon oder ein PDA. Der Client 101 kann eine virtuelle Maschine, wie z.B. eine JVM oder eine KVM, sein. Der Client 101 kann verwendet werden, um Anwendungen laufenzulassen, beispielsweise eine Java-Anwendung. Eine oder mehrere Anwendungen können auf dem Client 101 laufen, wobei typischerweise eine Anwendung ausgeführt wird und eine oder mehrere Anwendungen ausgesetzt sind. Die Anwendung 104 ist als die gerade ablaufende Anwendung dargestellt.
Der Speicher 115 kann integriert oder direkt an dem Gerät, welches den Client 101 aufweist, angebracht sein. Alternativ kann der Speicher 115 auf einem Gerät außerhalb und nur über die Ferne (beispielsweise über das Internet) mit dem Gerät verbunden sein, welches den Client 101 aufweist. Der Speicher 115 kann ein flüchtiger Speicher, wie z.B. ein direktes Inline-Speichermodul (DIMM) oder eine nicht-flüchtige Speichereinrichtung, wie z.B. ein Flash-Speicher, eine Festplatte oder eine herausnehmbare Platte wie z.B. eine Diskette, sein. Der Speicher 115 kann den virtuellen Heap 110 für die Anwendung 104 umfassen. Der Speicher 115 kann auch virtuelle Heaps (nicht dargestellt) für eine oder mehrere andere Anwendungen umfassen.
Der speicherinterne Heap 108 kann in dem Speicherraum des Client 101 gehalten werden oder kann alternativ in einem Speicher außerhalb des Speicherraumes des Client 101 gehalten werden. Der speicherinterne Heap 108 kann einen Teil des virtuellen Heap 110, der aktuell für die Verwendung durch die Anwendung 104 im Cache aufgenommen ist. Der speicherinterne Heap 108 und der virtuelle Heap 110 können in einen oder mehrere Abschnitte aufgeteilt sein. Die Abschnitte können Sektoren, Seiten, Cachezeilen oder irgendeine andere Aufteilung von Speicherraum sein. Wenn die Anwendung 104 Code oder Daten benötigt, die aktuell nicht in dem Heap 108 sind, so können einer oder mehrere Abschnitte des Heap 110 in den speicherinternen Heap 108 kopiert werden. Wenn es nicht ausreichend Platz in dem speicherinternen Heap 108 gibt, so können eine oder mehrere Abschnitte des speicherinternen Heap 108 entfernt werden, bevor die neuen Abschnitte kopiert werden.
Ein Abfallsammler 126 kann mit dem virtuellen persistenten Heap nach einem Plan und/oder nach Bedarf eine Abfallsammlung durchführen. Der virtuelle persistente Heap ist die Kombination des speicherinternen Heap 108 und des virtuellen Heap 110. Der virtuelle Heap 110 kann auch als der Speicherheap bezeichnet werden.
Die Abfallsammlung kann eine Kompaktierungsphase umfassen, um den Speicher in dem Heap nach dem Löschen von Objekten aus dem Heap kompakter zu machen. Abfallsammlung kann durch verschiedene Bedingungen ausgelöst werden. In einer Ausführungsform kann das Knappwerden von Speicherraum die Abfallsammlung auslösen, um Speicherraum freizumachen, in dem Objekte, die nicht aufgerufen werden, gelöscht werden und optional auch der Heap kompaktiert wird. In einer Ausführungsform kann eine Abfallsammlung nach einem Plan ausgelöst werden. Der Plan kann feste oder auch variable Intervalle aufweisen. In einer Ausführungsform kann die Abfallsammlung durch eine übermäßige Menge an Cachespeicherung ausgelöst werden. Eine übermäßige Menge an Cachespeicherung kann eine schlechte Objektlokalität anzeigen, was die Leistungsfähigkeit des Systems verschlechtert.
Eine schlechte Objektlokalität kann auftreten, wenn miteinander zusammenhängende bzw. korrelierte Objekte nicht im selben Abschnitt des Heap gespeichert sind. Beispielsweise kann eine schlechte Objektlokalität auftreten, wenn zwei oder mehr Objekte in einem Abschnitt des Heap nicht stark miteinander korreliert sind, wenn zwei oder mehr korrelierte Objekte in unterschiedlichen Abschnitten des Heap gespeichert sind oder bei einer Kombination dieser beiden Bedingungen. Korrelierte Objekte sind Objekte, die während der Ausführung einer Funktion der Anwendung verwendet werden können. Beispielsweise können ein Fenster, das verwendet wird, um Bilder anzuzeigen und eine Werkzeugleiste (Toolbar), die verwendet wird, um die Bilder zu bearbeiten, als unterschiedliche Objekte in einer Bildverarbeitungsanwendung gespeichert werden. Für eine gute Objektlokalität sollten diese Objekte auf derselben Seite des Heap gespeichert sein. Bei schlechter Objektlokalität könnten die Objekte Fenster und Toolbar auf unterschiedlichen Seiten gespeichert sein. Bei schlechter Objektlokalität könnte, während ein Benutzer das Bild in dem Fenster bearbeitet, die Seite, welche das Fensterobjekt enthält, in dem speicherinternen Heap 108 als Cache aufgenommen sein, während der Benutzer direkt das Objekt bearbeitet. Wenn es nicht genügend Platz in dem speicherinternen Heap gibt, könnte die Seite, welche die Menüleiste enthält, in dem virtuellen Heap 110 gespeichert werden. Wenn der Benutzer auf die Toolbar geht, um ein anderes Werkzeug zur Bearbeitung des Bildes auszuwählen, wird die Seite, welche das Fensterobjekt enthält, möglicherweise in den virtuellen Heap 110 ausgespült und die Seite, welche das Toolbarobjekt enthält, könnte dann in den speicherinternen Heap 108 als Cache aufgenommen werden. Nachdem der Benutzer das Werkzeug ausgewählt hat und zum Fenster zurückkehrt, um das Bild zu bearbeiten, wird möglicherweise die Seite, die das Objekt Toolbar enthält, ausgespült und die Seite, die das Objekt Fenster enthält, wieder Cache-gespeichert werden. Das konstante Umschichten von Seiten zwischen dem speicherinternen und dem virtuellen Heap kann die Leistungsfähigkeit des Systems beträchtlich verschlechtern und den Benutzer zwingen zu warten, während der Vorgang abgeschlossen wird.
Abfallsammlung in dem Heap zum Entfernen von Seiten, die nicht aufgerufen werden, und dann Kompaktieren bzw. Zusammenfassen des Heap kann die Objektlokalität verbessern. Das Kompaktieren des Heap kann das Verschieben von Objekten von einem Abschnitt des Heap in einen anderen Abschnitt umfassen, in welchem Heapraum während der Abfallsammlung freigemacht wurde, indem Objekte in dem Abschnitt gelöscht wurden, oder durch Verschieben von Objekten von dem Abschnitt in einen anderen Abschnitt. Das Verschieben von Objekten von ei nem Abschnitt in einen anderen Abschnitt des Heap kann dazu führen, daß korrelierte Objekte, die in unterschiedlichen Abschnitten des Heap waren, nunmehr in demselben Abschnitt des Heap gespeichert werden. In einer Ausführungsform können während der Kompaktierungsphase die Objekte in dem Heap untersucht werden, um korrelierte Objekte festzustellen, und es kann ein Versuch unternommen werden, soviel wie möglich korrelierte Objekte in demselben Abschnitt des Heap zu speichern. Dies kann das Verschieben von nicht miteinander korrelierten Objekten aus einem Abschnitt des Speichers heraus und das Verschieben von korrelierten Objekten in den Abschnitt des Speichers hinein umfassen.
Der Abfallsammler 126 kann am Grund des virtuellen persistenten Heap beginnen und Code und Daten, welche aufgerufen werden, mit einem Flag versehen (d.h. sie müssen in dem virtuellen persistenten Heap gehalten werden). Dann kann der gesamte Code und die Daten, die nicht mit einem Flag versehen sind, aus dem virtuellen persistenten Heap entfernt werden. Alternativ kann der Abfallsammler 126 Code und Daten mit einem Flag versehen, die nicht aufgerufen werden und kann dann die mit einem Flag versehenen Codes und Daten entfernen. In einer Ausführungsform können der Code und die Daten in Objekten vorliegen und der Abfallsammler kann Objekte in dem Heap untersuchen und für die Entfernung mit einem Flag versehen, welche nicht aufgerufen werden.
In einer Ausführungsform werden Objekte durch die Anwendung in dem speicherinternen Heap 108 erzeugt und können später in den virtuellen Heap 110 ausgespült werden, um in dem speicherinternen Heap 108 für die Erzeugung von weiteren neuen Objekten Platz freizumachen, oder damit angeforderte Objekte aus dem virtuellen Heap 110 in dem speicherinternen Heap 108 Cache-gespeichert werden. In einer Ausführungsform muß sich das Objekt in dem speicherinternen Heap befinden, damit die Anwendung auf ein Objekt zugreifen kann. Eine Anforderung durch die Anwendung nach einem Objekt, das sich gerade nicht in dem speicherinternen Heap 108 befindet, kann einen Heap-Lesevorgang auslösen, um das Objekt aus dem virtuellen Heap 110 in den speicherinternen Heap 108 zu verschieben.
Ein Objekt in dem Heap kann eines oder mehrere andere Objekte in dem Heap aufrufen und kann seinerseits selbst durch eines oder mehrere andere Objekte in dem Heap aufgerufen werden. Wenn ein Objekt aufgerufen wird, kann das Objekt als aktuell durch die Anwendung in Gebrauch befindlich betrachtet werden. Objekte, die nicht aufgerufen wurden, können als aktuell durch die Anwendung nicht verwendet betrachtet werden. Nicht aufgerufene Objekte können Kandidaten für eine Abfallsammlung sein.
In einer Ausführungsform kann ein Heap in Abschnitte aufgeteilt werden, beispielsweise in Seiten oder Cachezeilen. Die Abschnitte des Heap können in Sätze von zwei oder mehr Abschnitten oder in Arbeitssätze gruppiert sein, und zwar für Heapoperationen mit dem Heap, wie z.B. Abfallsammlung. Abschnitte des Heap können Strukturen zum Verwalten von Code und Daten (Objekten) umfassen, die in dem Abschnitt gespeichert sind. Eine Struktur zum Verfolgen der Aufrufe von Objekten kann als eine Objektaufruftabelle bezeichnet werden. In einer Ausführungsform können eine oder mehrere Objektaufruftabellen in einem Abschnitt des Heap gehalten wer den. In einer anderen Ausführungsform können eine oder mehrere Objektaufruftabellen in einem Arbeitssatz für die Abschnitte des Speichers in dem Arbeitssatz gehalten werden. In einer weiteren Ausführungsform kann eine globale Struktur zum Verfolgen der Aufrufe für alle Objekte in dem Heap außerhalb der Abschnitte des Speichers und/oder der Arbeitssätze aufbewahrt werden. In noch einer anderen Ausführungsform kann jedes Objekt Information über die Objekte enthalten, die es aufruft, sowie über die Objekte, durch die es aufgerufen wird. Ein interner Aufruf eines Objektes kann als Aufruf eines Objektes von einem anderen Objekt in demselben Abschnitt des Heap definiert werden. Ein externer Aufruf eines Objektes kann als ein Aufruf eines Objektes von einem anderen Objekt in einem anderen Abschnitt des Heap definiert werden. In einer Ausführungsform kann der Prozeß, um festzustellen, ob ein Objekt während einer Abfallsammlung aufgerufen wird, die Objektaufruftabelle untersuchen, welche die Aufrufinformation für das Objekt aufweist.
In einer Ausführungsform kann der virtuelle persistente Heap einen einzelnen Adreßraum sowohl für den virtuellen Heap 110 als auch für den speicherinternen Heap 108 verwenden. Ein einziger Abfallsammler 126 kann auf dem gesamten virtuellen, persistenten Heap-Adreßraum laufen. Der virtuelle persistente Heap kann einen einzigen Abfallsammler 126 verwenden, was für Einrichtungen mit Speicher- und CPU-Beschränkungen vorteilhaft sein kann, beispielsweise für kleine Anwendungs- und Verbrauchergeräte. Codes und Daten in dem speicherinternen Heap 108 können vor dem Start des Abfallsammlungszyklus in dem virtuellen Heap 110 ausgespült werden. Der Abfallsammler 126 muß also nur die Abfallsammlung auf dem virtuellen Heap 110 durchführen.
Die Abfallsammlung kann bewirken, daß der virtuelle persistente Heap zerstückelt wird, so daß ein großes Objekt nicht in einen verfügbaren freien Raum paßt. Eine Ausführungsform eines Abfallsammlungsverfahrens kann eine Kompaktierungsphase aufweisen, um diese Zerstückelung zu reduzieren oder zu beseitigen. Die Kompaktierungsphase kann auch die Objektlokalität verbessern.
Der virtuelle Heap ermöglicht das Laufen von Anwendungen, die einen speicherinternen Heap erfordern, der größer ist als der verfügbare. In einer Ausführungsform wird der Umfang der Cachespeicherung verfolgt und ein Abfallsammlungszyklus wird in Reaktion auf das Verfolgen der Menge an Cachespeicherung induziert, um zusätzliche Cachespeicherung zu reduzieren, bevor der virtuelle Heapspeicherraum knapp wird bzw. nicht mehr zur Verfügung steht.
Kleine Anwendungs- und Verbrauchergeräte können Flash-Einrichtungen für eine nichtflüchtige Speicherung verwenden. Flashgeräte haben typischerweise spezielle Eigenschaften, wie z.B. große I/O-Schreibblöcke (beispielsweise 128 Kbytes) und destruktive Schreibvorgänge. In einer Ausführungsform kann die Anzahl der Schreibvorgänge, die durch den Abfallsammler 126 mit der Einrichtung durchgeführt wird, minimal gemacht werden, um die Lebensdauer des Flashgerätes zu erhöhen. Der Abfallsammler 126 des virtuellen persistenten Heap kann unter Verwendung von Arbeitssätzen und/oder einer oder mehreren Objektschulen für kurzlebige Objekte implementiert werden.
Wenn eine Abfallsammelmethode in einem einzigen Zyklus durch den gesamten virtuellen Heapadreßraum läuft, kann ein großer Ausbruch an Cachebelastung und Spülanforderungen erzeugt werden, insbesondere wenn der speicherinterne Heap 108 viel kleiner als der virtuelle Heap 110 ist. Es kann ein Abfallsammler 126 auf Generationsbasis verwendet werden. Der virtuelle persistente Heap kann in Arbeitssätze aufgeteilt werden und jede Generation des Abfallsammlers 126 kann beschränkt werden auf einen Arbeitssatz des virtuellen persistenten Heap. Ein Arbeitssatz kann einen oder mehrere Abschnitte (Seiten, Cachezeilen, etc.) des virtuellen persistenten Heap umfassen. In einer Ausführungsform kann die Größe des Arbeitssatzes dieselbe sein wie die Größe des speicherinternen Heap. Der gesamte virtuelle persistente Heap kann in mehreren Zyklen (Generationen) des Abfallsammlers 126 einer Abfallsammlung auf den Arbeitssätzen ausgesetzt werden und jeder Zyklus kann eine Abfallsammlung mit einem oder mehreren der Arbeitssätze durchführen. Jeder Generationszyklus der Abfallsammlung kann nicht-zusammenhängende Bereiche des virtuellen persistenten Heap berühren bzw. erfassen. Ein kleiner Bereich des Heap kann gemeinsam verwendet werden, um Abhängigkeit zwischen den Arbeitssätzen zu speichern. Aufrufe können im wesentlichen auf den Bereich des Arbeitssatzes beschränkt werden. In einer Ausführungsform können die Zyklen der Abfallsammlung in festen Intervallen ablaufen. Alternativ können die Zyklen der Abfallsammlung in variierenden Abständen ablaufen.
In einer Ausführungsform kann ein Heapzuordner verwandten Code und Daten (beispielsweise korrelierte Objekte) in demselben Bereich von Arbeitssätzen kombinieren. Der Generationsabfallsammler 126 kann das Spülen von Anderungen vor, oder aternativ nach jedem Abfallsammlungszyklus für jeden Arbeitssatzbereich zulassen und kann damit den Cachespeicherungsausbruch eines Abfallsammlers, der in einem Zyklus den gesamten virtuellen Heap durchläuft, vermeiden. Der Generationsabfallsammler 126 kann es ermöglichen, daß die Cachebelastung und das Ausstoßen über mehrere Abfallsammlungsgenerationen verteilt bzw. ausgebreitet wird.
Während der Abfallsammlung kann der Standard-Spülmechanismus des virtuellen persistenten Heap abgeschaltet werden, bis die Abfallsammlung abgeschlossen ist. Da die Abfallsammlung wahrscheinlich den Heapzustand verändert und Heapstrukturen häufig aktualisiert, gibt es keinen Vorteil, wenn während der Abfallsammlung das Speichern eines Fixpunktes erzeugt wird. Beispielsweise wird eine Cachezeile während einer Abfallsammlung wahrscheinlich mehrere Male aktualisiert. Das Verfahren kann daher warten, bis die Abfallsammlung abgeschlossen ist, um eine Fixpunktspeicherung durchzuführen.
In einer Ausführungsform können Heapbereiche mit unterschiedlichen Spülstrategien verwendet werden. Beispielsweise kann ein Objektschulenbereich 113, der nicht ausgespült wird, wo Objekte für die Verwendung durch die Anwendung 104 anfänglich erzeugt werden, verwendet werden. In einer Ausführungsform können mehrfache Objektschulen mit unterschiedlichen Spülstrategien verwendet werden. Die Anwendung 104 kann neuen Code und Daten in den Schulbereichen ebenso wie in den Objektschulbereichen 113 des speicherinternen Heap 108 erzeugen.
Die Schulbereiche werden gegebenenfalls nicht ausgespült, im Gegensatz zu anderen Bereichen in dem speicherinternen Heap 108. Die Schulbereiche können dazu beitragen, die Zusatzlast durch Spülen, Zerstückelung und Abfallsammlung zu vermindern, indem die Anzahl neu erzeugter Objekte, die in den virtuellen Heap 110 ausgespült werden, reduziert wird, da kurzlebige, nicht-aufgerufene, neu erzeugte Objekte nicht gespült werden dürfen und damit während der Abfallsammlung nicht untersucht und entfernt werden müssen. In einer Ausführungsform kann ein Abfallsammler sowohl Arbeitssätze zur Implementierung einer Strategie der Generationsabfallsammlung als auch Heapbereiche mit unterschiedlichen Spülstrategien, wie z.B. Schulbereiche, verwenden.
In einer Ausführungsform können die Objekte in der Objektschule 113 als Teil der Abfallsammlung untersucht werden, um festzustellen, welche Objekte aufgerufen werden. In einer Ausführungsform kann die Information der Objektaufrufe für Objekte in der Objektschule 113 in einer Objektaufruftabelle in der Objektschule 113 gehalten werden. Aufgerufene Objekte können aus der Objektschule 113 in andere Bereiche des speicherinternen Heap 108 verschoben werden. Nicht aufgerufene Objekte können ebenfalls aus der Objektschule 113 entfernt werden. "Verunreinigte" Objekte, einschließlich der "neuen" Objekte, die aus der Objektschule 113 in andere Bereiche des speicherinternen Heap 108 verschoben wurden, können dann aus dem speicherinternen Heap 108 in den virtuellen Heap 110 ausgespült werden. Die Abfallsammlung kann dann nicht aufgerufene Objekte aus dem virtuellen Heap 110 entfernen. Eine Kompaktierungsphase kann dann den Speicher in den Abschnitten des virtuellen Heap 110 und/oder den Abschnitten des speicherinternen Heap 108 kompaktieren.
Bei objektorientierten Programmiersprachen, wie z.B. Java, können Objekte als Strukturen definiert werden, die Instanzen einer besonderen Klassendefinition oder Unterklassenobjektdefinition sind. Objekte können Instanzen der Methoden der Klasse oder Prozeduren (Code und/oder zugehörige Daten für das Objekt) umfassen. Ein Objekt ist das, was im eigentlichen Sinne in einem objektorientierten Programm in dem Computer "läuft".
Der Objektschulbereich wird eventuell nicht auf dieselbe Art und Weise gespült wie andere Bereiche des Heap 108. Eine Anzahl kurzlebiger Objekte kann während der Ausführung einer Anwendung erzeugt werden. Eine relativ kleine Anzahl dieser Objekte kann in dem persistenten Speicher enden. Die Verwendung einer Objektschule außerhalb des Umfangs des normalen Spülens und der Abfallsammlung zum Halten neuer Objekte vermeidet ein unnötiges Ausspülen der kurzlebigen Objekte. Objekte in der Objektschule, die durch andere Objekte in anderen Bereichen des virtuellen Heap extern aufgerufen werden, können gelegentlich in "normale" Heapbereiche kopiert werden, damit sie in den virtuellen Heap 110 ausgespült werden. In einer Ausführungsform können, wenn man einen Abfallsammlungszyklus laufen läßt, Objekte, die in der Objektschule aufgerufen wurden, in "normale" Heapbereiche kopiert werden, damit sie in den virtuellen Heap 110 ausgespült werden.
9 zeigt ein neues Objekt 128a, welches durch die Anwendung 104 in der Objektschule 113 erzeugt wurde. Wenn der Abfallsammler 126 läuft, kann das Objekt 128a in der Ob jektschule 113 untersucht werden. Wenn das Objekt durch die Anwendung 104 aufgerufen wird, ist es wahrscheinlich, daß das Objekt durch die Anwendung 104 auch in Zukunft verwendet werden wird. Das Objekt 128a kann dann als Objekt 128b in einen anderen Bereich des Heap 108 verschoben werden. Das Objekt 128b kann dann in den virtuellen Heap 110 als Objekt 128c ausgespült werden. Demnach existiert nunmehr das Objekt 128a in dem virtuellen Heap 110 als Objekt 128c. Der Speicherplatz für das Objekt 128a in der Objektschule 113 kann dann freigegeben werden, nachdem das Objekt 128a in einen anderen Bereich des speicherinternen Heap 108 verschoben wurde. Man beachte, daß das Objekt 128b (eine im Cache aufgenommene Kopie des Objektes 128c) in dem Heap 108 verbleiben kann, während es durch die Anwendung 104 in Gebrauch ist. Wenn ein Fixpunkt für den virtuellen Heap 110 erstellt wird, befindet sich das Objekt 128c in dem dauerhaften Speicher. Wenn eine Generation eines Abfallsammlers 126 auf dem Arbeitssatz des virtuellen Heap 110 läuft, der das Objekt 128c enthält, kann das Objekt 128c aus dem virtuellen Heap entfernt werden, wenn es durch die Anwendung 104 nicht mehr verwendet wird. Objekte in der „Schule" bzw. „Kinderstube" 113, die nach einer Generation einer Abfallsammlung nicht aufgerufen werden, können aus der Schule 113 entfernt werden.
Einige Ausführungsformen können zwei oder mehr Schulbereiche aufweisen. Die Bereiche können eine hierarchische Schule von Objekten bilden. In einer hierarchischen Schule kann ein Objekt in einem ersten Schulbereich erzeugt werden, wenn das Objekt in dem ersten Bereich "überlebt (aufgerufen ist, wenn die Objekte in dem ersten Schulbereich überprüft werden, wie z.B. während eines Abfallsammlungszyklus), kann das Objekt in einen zweiten Schulbereich für Objekte verschoben werden, die für eine gewisse Dauer erhalten geblieben sind. Das Objekt kann weiterhin überprüft werden und in "höhere" Schulbereiche verschoben werden, bis das Objekt schließlich in einen Bereich des speicherinternen Heap 108 verschoben wurde, oder bis das Objekt nicht mehr aufgerufen wird und aus den Schulbereichen gelöscht wird. Wenn das Objekt in einen Bereich des speicherinternen Heap verschoben wird, kann es anschließend aus dem speicherinternen Heap 108 in den virtuellen Heap 110 ausgespült werden. In einer Ausführungsform kann für neu erzeugte Objekte eine Zeitmarkierung beibehalten werden, um zu verfolgen, wie lange sie in einem Schulbereich geblieben sind, und das Objekt kann, nachdem eine gewisse Zeit verstrichen ist, in einen anderen Schulbereich oder aus dem Schulbereich heraus verschoben werden.
10a bis 10c – Abfallsammlung in einem virtuellen Heap
Die 10a bis 10c sind Flußdiagramme, welche Ausführungsformen eines Generationsabfallsammlers mit einer speziellen Bereichsverarbeitung zeigen. In einer Ausführungsform der Abfallsammlung, wie sie in 10a dargestellt ist, wird in Schritt 400 ein Prozeß auf einer virtuellen Maschine ausgeführt. In Schritt 402 kann ein Verwalter eines virtuellen Heap feststellen, ob für den Prozeß Abfallsammlung auf dem virtuellen Heap erforderlich ist. In einer Ausführungsform kann die Abfallsammlung auf einem Zeitintervall beruhen, beispielsweise etwa alle 15 Sekunden. In einer Ausführungsform kann das Knappwerden von Speicherraum in dem virtuellen Heap die Abfallsammlung auslösen, um Speicherraum des virtuellen Heap freizumachen. In einer Ausführungsform kann übermäßige Paging-Aktivität zwischen dem Speicherheap und dem virtuellen Heap eine Abfallsammlung auslösen. Ein übermäßiger Betrag an Paging kann ein Zeichen für eine schlechte Objektlokalität auf den Seiten sein; mit anderen Worten, der Prozeß könnte auf zwei oder mehr Objekte auf verschiedenen Seiten des Heap zugreifen, was bewirkt, daß einige Seiten aus dem speicherinternen Heap ausgespült werden, so daß andere Seiten cachegespeichert werden können. Abfallsammlung kann Platz auf Seiten in dem virtuellen Heap freimachen, was ermöglichen kann, daß die zwei oder mehr Objekte auf weniger Seiten zusammengedrückt werden und damit weniger Paging-Aktivität erfordern.
In einer Ausführungsform kann eine Abfallsammlung für den gesamten virtuellen Heap in einem Zyklus durchgeführt werden. Ein Zyklus kann eine oder mehrere Generationen der Abfallsammlung umfassen. In jeder Generation der Abfallsammlung kann die Abfallsammlung für einen oder mehrere Arbeitssätze des virtuellen Heap erfolgen. Ein Arbeitssatz kann eine oder mehrere Seiten des virtuellen Heap umfassen. Wenn in Schritt 404 eine Abfallsammlung erforderlich ist, so können spezielle Bereiche für den Prozeß verarbeitet werden. Spezielle Bereiche können einen oder mehrere Schulbereiche umfassen. In einer Ausführungsform können neue Objekte, die durch den Prozeß erzeugt werden, in einem oder mehreren Schulbereichen erzeugt werden. In Schritt 404 können neue Objekte, welche durch den Prozeß aufgerufen werden, in andere Bereiche des speicherinternen Heap 108 verschoben werden, und der Speicher in dem Schulbereich für andere Objekte, welche durch den Prozeß nicht aufgerufen wurden, kann freigemacht werden. Ein nächster Arbeitssatz in dem virtuellen Heap für den Prozeß kann dann in Schritt 406 eine Abfallsammlung erfahren. In einer Ausführungsform kann die Abfallsammlung für zwei oder mehr Arbeitssätze in einer Generation der Abfallsammlung erfolgen. In einer anderen Ausführungsform erfolgt die Abfallsammlung für einen Arbeitssatz in einer Generation der Abfallsammlung.
10b ist ein Flußdiagramm, welches die Verarbeitung eines Schul- bzw. Kinderstubenbereiches veranschaulicht. In Schritt 444 kann ein Objekt in dem Schulbereich untersucht werden. In Schritt 446 kann das Objekt, wenn es durch den Prozeß aufgerufen wird, in einen anderen Bereich in dem speicherinternen Heap verschoben werden, um in Schritt 448 in den dauerhaften Speicher ausgespült zu werden. Alternativ kann das Objekt in einer Hierarchie von zwei oder mehr Schulbereichen in einen "höheren" Schulbereich verschoben werden. Wenn das Objekt durch den Prozeß nicht aufgerufen wird, kann das Objekt in Schritt 450 aus dem Schulbereich gelöscht werden. In Schritt 452 kann die Verarbeitung, wenn es noch mehr neue Objekte in dem Schulbereich gibt, die noch nicht untersucht wurden, zu Schritt 444 zurückkehren, um das nächste Objekt zu untersuchen.
10c ist eine Erweiterung von Schritt 406 in 10a. In Schritt 418 können die Seiten, welche "verunreinigte" Objekte in dem speicherinternen Heap enthalten, in den virtuellen Heap ausgespült werden. In einer Ausführungsform können nur Seiten, welche verunreinigte Objekte in dem Arbeitssatz enthalten, der eine Abfallsammlung erfährt, in dieser Generation des Abfallsammlers ausgespült werden. In Schritt 420 können die Objekte in dem einen oder mehreren Arbeitssätzen, für die eine Abfallsammlung in dieser Generation erfolgt, untersucht werden. In Schritt 422 können Objekte, die durch die Anwendung nicht in Gebrauch sind oder nicht aufgerufen werden, für ein Entfernen markiert werden. In Schritt 424 werden Objekte, die für ein Entfernen aus dem einen oder den mehreren Arbeitssätzen markiert sind, aus dem virtuellen Speicher gelöscht werden. Alternativ können in Schritt 422 in Gebrauch befindliche Objekte markiert werden und in Schritt 424 werden dann unmarkierte Objekte entfernt. Eine weitere Alternative besteht darin, Objekte zu entfernen, wenn man feststellt, daß sie nicht in Gebrauch sind. In Schritt 426 können der eine oder die mehreren Arbeitssätze kompakt gemacht werden. Kompaktmachen bzw. Kompaktieren des einen und der mehreren Arbeitssätze kann das Verschieben eines oder mehrerer Objekte in einem Arbeitssatz an eine andere Stelle in dem Arbeitssatz umfassen, oder das Verschieben von einem oder mehreren Objekten in einen anderen Arbeitssatz, um soviel zusammenhängenden freien Raum wie möglich in dem Heap zu gewinnen.
11a bis 11c – Unteilbare Transaktionen auf einem persistenten Speicher
Eine Datenbankspeichermethode und eine Anwendungsprogrammierschnittstelle (API) können für den virtuellen persistenten Heap vorgesehen sein. Die API kann Mechanismen für die Cachespeicherung von Teilen des virtuellen Heap in den speicherinternen Heap für die Verwendung durch die Anwendung und für das Spülen von Teilen des Heaps aus dem speicherinternen Heap heraus bereitstellen. Der virtuelle Heap kann in einem persistenten Speicher gespeichert werden. Die Datenbankspeichermethode und die API können also so funktionieren, daß sie den virtuellen persistenten Heap in dem persistenten Speicher verwalten.
In einer Ausführungsform besteht der persistente Speicher aus einem oder mehreren virtuellen persistenten Heaps, wobei je ein virtueller persistenter Heap für jede Anwendung vorgesehen ist, die in der virtuellen Maschine läuft. Jeder virtuelle persistente Heap kann in Cachezeilen aufgeteilt sein. Die Cachezeile ist die kleinste Datenmenge, die in dem Heap gelesen oder geschrieben werden kann.
Die Datenbankspeicher-API kann eine Schnittstelle zu einem Satz von Funktionen zum Verwalten eines virtuellen persistenten Heap in einer virtuellen Maschinenumgebung umfassen. Die Datenbankspeichermethode und API können so ausgestaltet sein, daß sie mit kleinen Verbraucher- und eingebetteten Einrichtungen, wie z.B. Java-Einrichtungen, ebenso wie mit größeren Einrichtungen und Geräten arbeiten, die Java und andere virtuelle Maschinenumgebungen unterstützen, wie z.B. PCs, Laptops, etc. Die durch die Datenbankspeicher-API bereitgestellten Funktionen können so ausgestaltet sein, daß sie Transaktionen zum Verwalten des virtuellen persistenten Heap ausführen. Zumindest einige der Transaktionen können unteilbare Transaktionen sein. Die Transaktionen, welche durch die Datenbankspeicher-API bereitgestellt werden, können die folgenden umfassen, ohne jedoch hierauf beschränkt zu sein:

• Öffnen des Speichers
• Schließen des Speichers
• Unteilbarer Lesevorgang (Lesen eines Satzes von Cachezeilen)
• Unteilbarer Schreibvorgang (Schreiben eines Satzes von Cachezeilen)
• Unteilbare Löschtransaktion (Löschen eines Satzes von Cachezeilen)
• Abort (Stoppen einer Transaktion)

Die 11a bis 11c veranschaulichen mehrere Datenbankspeicher API-Transaktionen, die in Ausführungsformen der vorliegenden Erfindung verfügbar sein könnten. Eine unteilbare Transaktion kann als eine Folge von Informationsaustausch und damit verwandten Arbeiten definiert werden, die für die Zwecke der Erfüllung einer Anforderung und für das Sicherstellen von Datenintegrität als eine Einheit betrachtet wird. Damit eine Transaktion abgeschlossen wird und Datenveränderungen dauerhaft gemacht werden, muß eine Transaktion in ihrer Gesamtheit abgeschlossen werden. Wenn eine Transaktion insgesamt erfolgreich abgeschlossen wurde, so ist die Transaktion in Kraft. Das In-Kraft-Setzen einer Transaktion umfasst das Annehmen aller Veränderungen, die durch die Transaktion vorgenommen wurden. Wenn die Transaktion nicht erfolgreich abgeschlossen wird, kann sie zurückgewiesen werden und alle Daten, die durch die Transaktion beeinfluß wurden, können in den Zustand der Daten zu irgendeinem früheren Zeitpunkt "zurückabgewickelt" werden, beispielsweise auf den Zustand der Daten zu dem Zeitpunkt, zu welchem die Transaktion begann.
Als ein Beispiel einer unteilbaren Transaktion kann, wenn zwei Cachezeilen aus dem Cache herausgespült und in den persistenten Heap geschrieben werden und wenn es eine Beziehung zwischen den beiden Cachezeilen gibt, welche erfordert, daß die beiden konsistent sind, eine unteilbare Schreibtransaktion von der Datenbank-API aufgerufen werden, um beide Cachezeilen zu schreiben. Wenn beide Cachezeilen erfolgreich aus dem speicherinternen Heap gelesen wurden und in den Speicherheap geschrieben wurden, so ist die Transaktion in Kraft und die Verarbeitung wird wieder aufgenommen. Wenn die erste Cachezeile erfolgreich geschrieben wurde, jedoch die zweite Cachezeile nicht geschrieben wird, so wird das Schreiben der ersten Cachezeile rückgängig gemacht ("zurückabgewickelt") und der Zustand des speicherinternen Heap und des virtuellen Heap wird wieder auf den Zustand vor Beginn des unteilbaren Schreibvorganges hergestellt.
11a veranschaulicht eine Ausführungsform einer unteilbaren Lesetransaktion. Eine unteilbare Lesetransaktion kann erfolgen, wenn eine Anwendung Code und/oder Daten (Objekte) erfordert, die aktuell nicht in dem speicherinternen Heap sind, sich jedoch in dem Speicherheap befinden. Die unteilbare Lesetransaktion kann die eine oder mehreren Cachezeilen, einschließlich der erforderlichen Objekte für die Anwendungen aus dem Speicherheap, in den speicherinternen Heap cache-speichern.
Der Speicherheap kann in Schritt 500 geöffnet werden. In einer Ausführungsform kann sich der Speicherheap in einem von mehreren Zugriffszuständen, einschließlich eines offenen Zugriffszustandes und eines geschlossenen Zugriffszustandes, befinden. In dem offenen Zugriffszustand können Operationen, wie z.B. Schreiben, Lesen und Löschen von Cachezeilen in dem Speicherheap zulässig sein. In dem geschlossenen Zugriffszustand können diese Operatio nen verboten sein. Das Öffnen des Speicherheap kann das Ändern des Zustandes aus geschlossen nach offen umfassen.
Die Schritte 502 bis 506 veranschaulichen die unteilbare Lesetransaktion. In Schritt 502 können eine oder mehrere Cachezeilen aus dem Speicherheap gelesen werden. Die einen oder mehreren Zeilen, die aus dem Speicherheap gelesen werden, können in Schritt 504 in dem speicherinternen Heap cache-gespeichert werden. Wenn es in dem speicherinternen Heap nicht genügend Speicherplatz für die Cachezeilen gibt, kann durch eines oder mehrere von verschiedenen Verfahren mehr Speicherraum in dem speicherinternen Heap verfügbar gemacht werden. Beispiele von Verfahren zum Verfügbarmachen von mehr Speicherraum in dem speicherinternen Heap umfassen (ohne Beschränkung): Zuweisen von mehr Cachezeilen zu dem speicherinternen Heap, Ausspülen von einer oder mehreren Cachezeilen in den Speicherheap, Löschen von unbenutztem oder vorübergehendem Inhalt aus einer oder mehreren Cachezeilen und Kompaktieren des Speichers in einer oder mehreren Cachezeilen. In Schritt 506 kann die Transaktion, nachdem sie erfolgreich abgeschlossen wurde, in Kraft gesetzt werden. Wenn die Transaktion fehlschlägt, so kann sie nicht in Kraft gesetzt werden und Daten, die während der Transaktion modifiziert wurden, können in ihren Zustand vor Beginn der Transaktion "zurückabgewickelt" werden. Das Zurückabwickeln eines unteilbaren Lesevorganges kann das Rückgängigmachen jeglicher Cachespeicherung von Cachezeilen in dem speicherinternen Heap, die in Schritt 504 vorgenommen wurden, umfassen. In Schritt 530 kann der Speicherheap geschlossen werden. Das Schließen des Speicherheap kann das Verändern des Zustandes von offen nach geschlossen aufweisen.
11b veranschaulicht eine Ausführungsform einer unteilbaren Schreibtransaktion. Eine unteilbare Schreibtransaktion kann erfolgen, wenn es Objekte gibt, die aus dem speicherinternen Heap in den Speicherheap gespült werden sollen. Die Objekte können "verunreinigte" Objekte sein, die in dem Speicherheap aktualisiert werden müssen, oder sie können neue Objekte sein, die in den Speicherheap ausgespült werden müssen.
In Schritt 500 kann der Speicherheap geöffnet werden. Schritte 510 bis 514 veranschaulichen die unteilbare Schreibtransaktion. In Schritt 510 können eine oder mehrere Cachezeilen, einschließlich der auszuspülenden Objekte, aus dem speicherinternen Heap ausgespült werden. In Schritt 512 können die einen oder mehreren Cachezeilen in den Speicherheap geschrieben werden. Wenn es für die Cachezeilen nicht genügend Speicher in dem Speicherheap gibt, so kann mehr Speicherraum in dem Speicherheap durch eine oder mehrere von verschiedenen Methoden verfügbar gemacht werden. Beispiele von Methoden zum Verfügbarmachen von mehr Speicherraum in dem Speicherheap umfassen (ohne Beschränkung): Zuweisen von mehr Cachezeilen in den Speicherheap, Löschen einer oder mehrerer Cachezeilen aus dem Speicherheap, Löschen von unbenutztem oder vorübergehendem Inhalt aus einer oder mehreren Cachezeilen und Kompaktieren von Speicher in einer oder mehreren Cachezeilen. In Schritt 514 kann die Transaktion, nachdem sie erfolgreich abgeschlossen wurde, in Kraft gesetzt werden. Wenn die Transaktion fehlschlägt, so kann sie nicht in Kraft gesetzt werden und Daten, die wäh rend der Transaktion modifiziert wurden, können in ihren Zustand vor Beginn der Transaktion "zurückabgewickelt" werden. In Schritt 530 kann der Speicherheap geschlossen werden.
11c veranschaulicht eine Ausführungsform einer unteilbaren Löschtransaktion. Eine unteilbare Löschtransaktion kann erfolgen, wenn es Objekte gibt, die aus dem Speicherheap entfernt werden sollen, wie z.B. dann, wenn die Objekte nicht aufgerufene Objekte sind, die für ein Entfernen aus dem Speicherheap während der Abfallsammlung ausgewählt wurden. Die Objekte können als durch die Anwendung aktuell nicht verwendet festgestellt werden. In Schritt 500 kann der Speicherheap geöffnet werden. Die Schritte 520 und 522 veranschaulichen die unteilbare Löschtransaktion. In Schritt 520 können eine oder mehrere Cachezeilen, welche die Objekte enthalten, aus dem Speicherheap gelöscht werden. In Schritt 522 kann die Transaktion, nachdem sie erfolgreich abgeschlossen wurde, in Kraft gesetzt werden. Wenn die Transaktion fehlschlägt, kann die Transaktion nicht in Kraft gesetzt werden und Daten, welche während der Transaktion modifiziert wurden, können in ihren Zustand vor Beginn der Transaktion "zurückabgewickelt" werden. In Schritt 530 kann der Speicherheap geschlossen werden. Die Cachezeilen, welche die aus dem Speicherheap zu entfernenden Objekte enthalten, können, bevor sie gelöscht werden, aus dem speicherinternen Heap ausgespült werden.
In den 11a bis 11c kann das öffnen und Schließen des Speicherheap optional erfolgen. Wenn beispielsweise der Speicherheap bereits geöffnet ist, so ist Schritt 500 eventuell nicht notwendig, und wenn andere Transaktionen absehbar sind, so muß der Speicherheap nicht geschlossen werden.
Verschiedene Ausführungsformen können weiterhin das Empfangen oder Speichern von Befehlen und/oder Daten umfassen, die gemäß der vorstehenden Beschreibung mit einem Trägermedium implementiert wurden. Geeignete Trägermedien können Speichermedien wie z.B. magnetische oder optische Medien, z.B. eine Diskette oder eine CD-ROM, ebenso wie Übertragungsmedien oder Signale sein, die z.B. elektrische, elektromagnetische oder digitale Signale umfassen, die über ein Kommunikationsmedium, wie z.B. ein Netzwerk 108 und/oder eine drahtlose Verbindung übertragen werden können.
Auch wenn die obigen Ausführungsformen im einzelnen beschrieben worden sind, liegen für Fachleute auf diesem Gebiet bei vollständiger Berücksichtigung der obigen Beschreibung zahlreiche Variationen und Modifikationen auf der Hand.

Claims

Verfahren zum Verwalten eines virtuellen Speichers in einer virtuellen Maschine, wobei das Verfahren aufweist: Ausführen eines Prozesses in der virtuellen Maschine, wobei die virtuelle Maschine einen Verwalter eines virtuellen Speichers der virtuellen Maschine aufweist, wobei der Verwalter des virtuellen Speichers der virtuellen Maschine Objekte für den Prozess speichert, der auf der virtuellen Maschine abläuft, um einen Heap zu speichern, der eine vollständige Kopie eines virtuellen Heaps (110) für den Prozess umfasst, wobei die Objekte für die Verwendung während der Ausführung des Prozesses vorgesehen sind, der Prozess ein erstes der in dem Speicher-Heap gespeicherten Objekte aufruft, und der Verwalter des virtuellen Speichers der virtuellen Maschine einen Abschnitt des Speicher-Heaps einschließlich des ersten Objektes in einem innerhalb des Speichers liegenden Heap (108) kopiert, und zwar unter Reaktion auf das Aufrufen des ersten Objektes durch den Prozess, wobei der innerhalb des Speichers liegende Heap Kopien von Abschnitten des Speicher-Heaps für den Prozess aufweist und wobei das Kopieren durchgeführt wird, wenn das durch den Prozess aufgerufene erste Objekt sich in dem Abschnitt des Speicher-Heaps befindet und nicht in dem innerhalb des Speichers liegenden Heap, wenn das erste Objekt durch den Prozess aufgerufen wird.
Verfahren nach Anspruch 1, welches aufweist: Modifizieren des ersten Objektes in dem innerhalb des Speichers liegenden Heap durch den Prozess, und Ersetzen des Abschnittes des Speicher-Heaps durch die Kopie des Abschnittes aus dem innerhalb des Speichers liegenden Heap einschließlich des ersten Objektes in Reaktion auf das Modifizieren des ersten Objektes des innerhalb des Speichers liegenden Heaps, und zwar durch den Verwalter des virtuellen Speichers der virtuellen Maschine.
Verfahren nach Anspruch 2, welches weiterhin aufweist: Entfernen der Kopie des Abschnittes aus dem innerhalb des Speichers liegenden Heap nach dem Ersetzen des Abschnittes des Speicher-Heaps durch den Verwalter des virtuellen Speichers der virtuellen Maschine.
Verfahren nach einem der vorstehenden Ansprüche, wobei die virtuelle Maschine auf einer Einrichtung abläuft, wobei die Einrichtung einen Speicher aufweist, und wobei die virtuelle Maschine in dem Speicher abläuft, den die Einrichtung aufweist.
Verfahren nach Anspruch 4, wobei die Einrichtung keinen ausreichenden Ausführungsspeicher hat, um einen vollständigen Heap für den Prozess zu speichern, der auf der virtuellen Maschine abläuft.
Verfahren nach Anspruch 4 oder 5, wobei die Einrichtung eine Client-Einrichtung in einem Netzwerk ist.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Prozess in einem ersten Speicherraum abläuft, den die virtuelle Maschine aufweist, wobei der innerhalb des Speichers liegende Heap in dem ersten Speicherraum enthalten ist, wobei eine Gesamtgröße des Speicherheaps größer ist als der verfügbare Speicherraum in dem ersten Speicher und wobei der Speicherheap in einem zweiten Speicherraum enthalten ist.
Verfahren nach einem der vorstehenden Ansprüche, wobei die virtuelle Maschine auf einer Einrichtung abläuft, und wobei der Speicherhaufen in einer mit der Einrichtung verbundenen Speichereinrichtung enthalten ist.
Verfahren nach Anspruch 8, wobei die Speichereinrichtung, die mit der Einrichtung verbunden ist, eine nicht-flüchtige Speichereinrichtung ist.
Verfahren nach Anspruch 8 oder 9, wobei die Speichereinrichtung, die mit der Einrichtung verbunden ist, ein Flash-Speicher ist, wobei der Speicher-Heap eine Mehrzahl von Cache-Zeilen aufweist, und wobei der Abschnitt des Speicherhaufens eine oder mehrere aus der Mehrzahl von Cache-Zeilen aufweist.
Verfahren nach einem der Ansprüche 8 bis 10, wobei die Speichereinrichtung, welche den Speicher-Heap aufweist, mit der Einrichtung über das Internet verbunden ist, so dass das Kopieren des Abschnittes des Speicher-Heap in den innerhalb des Speichers liegenden Heap durch den Verwalter des virtuellen Speichers der virtuellen Maschine über das Internet erfolgt.
Verfahren nach einem der vorstehenden Ansprüche, wobei die virtuelle Maschine eine virtuelle Java-Maschine ist, und wobei der Vorgang eine Java-Anwendung ist.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Speicher-Heap einer aus einer Mehrzahl von Speicher-Heaps in einem dauerhaften Speicher ist, wobei jeder aus der Mehrzahl von Speicher-Heaps zu einem aus einer Mehrzahl von Prozessen gehört, und wobei der Prozess einer aus der Mehrzahl von Prozessen ist.
Verfahren nach irgendeinem der vorstehenden Ansprüche, wobei die Objekte, die in dem speicherinternen Heap und dem Speicher vorhanden sind, Code und Daten für die Verwendung durch den Prozess während der Ausführung in der virtuellen Maschine aufweisen.
System, welches aufweist: ein Gerät, welches dafür ausgelegt ist, eine virtuelle Maschine auszuführen, wobei die virtuelle Maschine so ausgestaltet ist, dass sie einen Prozess ausführt, einen ersten Speicher (115), der mit der Einrichtung verbunden ist, wobei der erste Speicher so ausgestaltet ist, dass er einen Speicher-Heap für den Prozess speichert, wobei der Speicher-Heap innerhalb eines virtuellen Heap (110) für den Prozess vorliegt und eine vollständige Kopie des virtuellen Heap umfasst, einen zweiten Speicher, der mit der Einrichtung verbunden ist, wobei der zweite Speicher so ausgestaltet ist, dass er einen speicherinternen Heap (108) für den Prozess speichert, wobei der speicherinterne Heap innerhalb des virtuellen Heaps vorhanden ist, wobei der speicherinterne Heap in einem Cache aufgenommene Teile des Speicher-Heaps für den Zugriff durch den Prozess aufweist, wobei die Einrichtung weiterhin so ausgestaltet ist, dass sie eine Verwaltung eines virtuellen Speichers in einer virtuellen Maschine ausführt, wobei die Verwaltung des virtuellen Speichers der virtuellen Maschine so ausgestaltet ist, dass sie: Objekte für den Prozess, der auf der virtuellen Maschine abläuft, in dem Speicher-Heap speichert, wobei die Objekte für die Verwendung während der Ausführung des Prozesses vorgesehen sind, und einen Abschnitt des Speicher-Heaps einschließlich eines ersten Objektes in einen speicherinternen Heap speichert, und zwar in Reaktion darauf, dass der Prozess das erste Objekt aufruft, wenn das erste durch den Prozess aufgerufene Objekt sich in dem Abschnitt des Speicher-Heaps und nicht in dem speicherinternen Heap befindet.
System nach Anspruch 15, wobei die Verwaltung des virtuellen Speichers der virtuellen Maschine weiterhin so ausgestaltet ist, dass sie: den Abschnitt des Speicher-Heaps durch die Kopie des Abschnittes aus dem speicherinternen Heap einschließlich des ersten Objektes ersetzt, und zwar in Reaktion darauf, dass der Prozess das erste Objekt in dem speicherinternen Heap modifiziert, und die Kopie aus dem Abschnitt des speicherinternen Heaps nach dem Ersetzen des Abschnittes des Speicher-Heaps entfernt.
System nach Anspruch 15 oder 16, wobei der zweite Speicher nicht ausreicht, um einen vollständigen Heap für den auf der virtuellen Maschine ablaufenden Prozess zu speichern.
System nach einem der Ansprüche 15 bis 17, wobei die Einrichtung eine Client-Einrichtung in einem Netzwerk ist.
System nach einem der Ansprüche 15 bis 18, wobei der Prozess in dem zweiten Speicher abläuft, und wobei eine Gesamtgröße des Speicher-Heaps größer ist als der verfügbare Speicherraum in dem zweiten Speicher.
System nach einem der Ansprüche 15 bis 19, wobei der erste Speicher, der mit der Einrichtung verbunden ist, ein Flash-Speicher ist, wobei der Speicher-Heap eine Mehrzahl von Cache-Zeilen aufweist, und wobei der Abschnitt des Speicher-Heap eine oder mehrere aus der Mehrzahl von Cache-Zeilen aufweist.
System nach einem der Ansprüche 15 bis 20, wobei der erste Speicher über das Internet mit der Einrichtung verbunden ist, so dass das Speichern des Abschnittes des Speicher-Heaps in den speicherinternen Heap durch die Verwaltung des virtuellen Speichers der virtuellen Maschine über das Internet erfolgt.
System nach einem der Ansprüche 15 bis 21, wobei die virtuelle Maschine eine virtuelle Java-Maschine ist und wobei der Prozess eine Java-Anwendung ist.
System nach einem der Ansprüche 15 bis 22, welches weiterhin aufweist: dass der erste Speicher einen dauerhaften Speicher aufweist, der so ausgestaltet ist, dass er eine Mehrzahl von Speicher-Heaps speichert, und wobei jeder aus der Mehrzahl von Speicher-Heaps zu einem aus einer Mehrzahl von Prozessen gehört, und wobei der Speicher-Heap für den Prozess einer aus der Mehrzahl von Speicher-Heaps und der Prozess einer aus der Mehrzahl von Prozessen ist.
System nach einem der Ansprüche 15 bis 23, wobei die Objekte, die in dem speicherinternen Heap und dem Speicher-Heap vorhanden sind, Code und Daten für die Verwendung durch den Prozess während der Ausführung innerhalb der virtuellen Maschine aufweisen.
Trägermedium, welches Programmieranweisungen aufweist, die so ausführbar sind, dass sie einen virtuellen Speicher in einer virtuellen Maschine verwalten, wobei die virtuelle Maschine eine Verwaltung eines virtuellen Speichers einer virtuellen Maschine aufweist, und wobei die Programmanweisungen so ausführbar sind, dass sie implementieren: Speichern von Objekten für einen Prozess, der auf der virtuellen Maschine abläuft, in einem Speicher-Heap einschließlich einer vollständigen Kopie eines virtuellen Heaps (110) für den Prozess, wobei die Objekte für die Verwendung während der Ausführung des Prozesses vorgesehen sind, und Kopieren eines Abschnittes des Speicher-Heaps einschließlich eines ersten Objektes in einem speicherinternen Heap (108) in Reaktion darauf, dass der Prozess das erste Objekt aufruft, wobei der speicherinterne Heap Kopien von Abschnitten des Speicher-Heaps für den Prozess aufweist, und wobei das Kopieren ausgeführt wird, wenn das erste durch den Prozess aufgerufene Objekt sich in dem Abschnitt des Speicher-Heaps und nicht in dem speicherinternen Heap befindet, wenn das erste Objekt durch den Prozess aufgerufen wird.
Trägermedium nach Anspruch 25, wobei die Programmanweisungen so ausführbar sind, dass sie folgendes implementieren: Ersetzen des Abschnittes des Speicher-Heaps durch die Kopie des Abschnittes des speicherinternen Heaps einschließlich des ersten Objektes unter Ansprechen darauf, dass der Prozess das erste Objekt in dem speicherinternen Heap modifiziert, und Entfernen der Kopie des Abschnittes aus dem speicherinternen Heap, nach dem Ersetzen des Abschnittes des Speicher-Heaps.
Trägermedium nach Anspruch 25 oder 26, wobei die virtuelle Maschine auf einer Einrichtung abläuft, wobei die Einrichtung einen Speicher aufweist, wobei die virtuelle Maschine in dem Speicher, welchen die Vorrichtung aufweist, abläuft, und wobei die Einrichtung nicht genügend Ausführungsspeicher für die Speicherung eines vollständigen Heap für den auf der virtuellen Maschine ablaufenden Prozess hat.
Trägermedium nach einem der Ansprüche 25 bis 27, wobei der Prozess in einem ersten Speicherraum abläuft, der in der virtuellen Maschine vorhanden ist, wobei der speicherinterne Heap in dem ersten Speicherraum vorhanden ist, wobei die Gesamtgröße des Speicher-Heaps größer ist als der verfügbare Speicherraum in dem ersten Speicherraum, und wobei der Speicher-Heap in einem zweiten Speicherraum vorhanden ist.
Trägermedium nach einem der Ansprüche 25 bis 28, wobei die virtuelle Maschine auf einer Einrichtung abläuft, und wobei der Speicher-Heap in einer mit der Einrichtung verbundenen Speichereinrichtung vorhanden ist.
Trägermedium nach Anspruch 29, wobei die Speichereinrichtung, die mit der Einrichtung verbunden ist, ein Flash-Speicher ist, wobei der Speicher-Heap eine Mehrzahl von Cache-Zeilen aufweist, und wobei der Abschnitt des Speicher-Heaps eine oder mehrere aus der Mehrzahl von Cache-Zeilen aufweist.
Trägermedium nach Anspruch 29 oder 30, wobei die Speichereinrichtung, welche den Speicher-Heap aufweist, über das Internet mit der Einrichtung verbunden ist, so dass das Speichern des Abschnittes des Speicher-Heaps in den speicherinternen Heap durch die Verwaltung des virtuellen Speichers der virtuellen Maschine über das Internet erfolgt.
Trägermedium nach einem der Ansprüche 25 bis 31, wobei die virtuelle Maschine eine virtuelle Java-Maschine ist und wobei der Prozess eine Java-Anwendung ist.
Trägermedium nach einem der Ansprüche 25 bis 32, wobei der Speicher-Heap einer aus einer Mehrzahl von Speicher-Heaps in einem dauerhaften Speicher ist, wobei jeder aus der Mehrzahl von Speicher-Heaps zu einem aus einer Mehrzahl von Prozessen gehört, und wobei der Prozess einer aus der Mehrzahl von Prozessen ist.
Trägermedium nach einem der Ansprüche 25 bis 33, wobei die Objekte, die in dem speicherinternen Heap und in dem Speicher-Heap vorhanden sind, Code und Daten für die Verwendung durch den Prozess während der Ausführung innerhalb der virtuellen Maschine aufweisen.