DE60100932T2

DE60100932T2 - Ein Speicherverwaltungsgerät, -methode,-programm und rechnerlesbares Speichermedium zum Speichern des Speicherverwaltungsprogrammes

Info

Publication number: DE60100932T2
Application number: DE60100932T
Authority: DE
Inventors: Yuko Hiroshima-shi Kubooka; Shigenori Hiroshima-shi Doi
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp
Priority date: 2000-12-11
Filing date: 2001-12-10
Publication date: 2004-08-12
Anticipated expiration: 2021-12-11
Also published as: DE60100932D1; JP4295805B2; EP1213649A1; US6934821B2; EP1359505B1; DE60114667D1; US20020095556A1; JP2008234668A; EP1359505A1; DE60114667T2; EP1213649B1

Description

Die vorliegende Erfindung betrifft digitale Computersoftware und insbesondere eine Speicherverwaltungsvorrichtung zum Verwalten eines Speichers, in dem ein auf einem objektorientierten Programm auszuführendes Ausführungsobjekt gespeichert ist, ein Speicherverwaltungsverfahren, ein Speicherverwaltungsprogramm und ein computerlesbares Aufzeichnungsmedium, in dem das Programm aufgezeichnet wird.
Mit dem Fortschritt in der Computertechnologie, der Kommunikations- und Rundsendetechnologie in den letzten Jahren verbreiten sich Multimedia-Systeme, die verschiedene Informationsmedien anbieten, wie zum Beispiel Bilder, Klänge und Spielfilme. Zu solchen Multimediasystemen auf dem Markt gehören das interaktive digitale Fernsehen, bewegliche Endgeräte, Spielmaschinen oder dergleichen.
In Multimediasystemen werden großvolumige Daten, die über Kommunikationsmedien wie das Internet übertragen werden, wie zum Beispiel Bild-, Klang- und bewegliche Bilddaten mit einer Anwendung in den Multimediasystemen kombiniert und werden Benutzern als Bild und Klang von dem Bildschirm, Lautsprecher usw. angeboten. Deshalb wird in den Multimediasystemen Technologie zur effizienten Verarbeitung eines großen herunterzuladenden Datenvolumens benötigt.
In den letzten Jahren verbreitet sich die Umgebung der objektorientierten Sprache „Java" (eingetragenes Warenzeichen) der Sun Microsystems als eine Technik zur Materialisierung einer effizienten Stromverarbeitung großvolumiger Daten, wie zum Beispiel Bild-, Klang- und Spielfilmdaten aus Kommunikationsmedien.
Als ein Beispiel für die herkömmlichen vorbekannten Techniken für eine aus einem Programm, das in Java beschrieben wird, gebildete Anwendung (im folgenden „Java-Anwendung") wird nun der Verarbeitungsfluß erläutert, in dem Bilddaten über Kommunikationsmedien wie zum Beispiel das Internet gemäß einer Anforderung von Java-Anwendung heruntergeladen und dann in Java-Anwendung verwendet werden.
10 ist ein Funktionsblockschaltbild einer allgemeinen Speicherverwaltungsvorrichtung zum Herunterladen von Bilddaten gemäß einer Anforderung von Java-Anwendung und zur Ausführung von Java-Anwendung in einer Multimedia-Umgebung.
Die in 10 gezeigte Speicherverwaltungsvorrichtung ist aus einer Java-Anwendung 11 bzw, einem aus der Java-Sprache gebildeten Programm, dem Java-Virtual-Machine-Programm (im folgenden Java VM) 12, dem nativen Programm 13, dem Betriebssystem (OS) 14 und einem Objektspeicherteil 15 zusammengesetzt.
Die Java-Anwendung 11 weist einen in Java beschriebenen Quellcode auf und wird kompiliert und in einen niedrigen Pseudocode umgesetzt, d. h. in einen Zwischencode (im folgenden Bytecode). Der Bytecode wird in eine Maschinensprache umgesetzt, die durch Computer interpretiert und ausgeführt werden kann (im folgenden „nativer Code") und wird ausgeführt. Durch diese Funktion der Java VM 12 kann eine Umgebung in Java, die in einer beliebigen Plattform ausgeführt werden kann, ohne Abhängigkeit von einem spezifischen OS oder Prozessor materialisiert werden.
Die Java VM 12 besteht aus einem Interpretiererteil 12a, einem Objektverwaltungsteil 12b und dem Teil 12c für die Java Native Interface (JNI). Aus der Java-Anwendung 11 liest der Interpretiererteil 12a einen Bytecode zur Darstellung einer Anweisung aus, setzt die Anweisung in einen nativen Code um und führt die Anweisung aus. Der Objektverwaltungsteil 12b erzeugt Daten oder Quellcode (im folgenden „Java-Objekt") zur Verwendung zur Ausführung der Java-Anwendung 11 oder bezieht sich auf erzeugte Java-Objekte.
Hierbei ist das Java-Objekt ein durch Java-Klasse definierter Bytecode und wird in dem Objektspeicherteil 15 durch den Objektverwaltungsteil 12b gemäß einer Anforderung der Java-Anwendung 11 generiert oder instanziiert. Das instanziierte Java-Objekt alleine wird bei der Ausführung durch die Java-Anwendung 11 als Ausführungsobjekt benutzt.
Der JNI-Teil 12c materialisiert eine Anwendungsprogrammschnittstelle (API), die aus einer Menge von Anweisungen und Funktionen zur Ausführung des in C-Sprache beschriebenen nativen Programms 13 usw. gemäß einer Anforderung der Java-Anwendung 11 besteht. Außerdem kann der JNI-Teil 12c die Java VM die Java-Anwendung 11 gemäß einer Anforderung aus dem nativen Programm 13 ausführen lassen.
Der Objektspeicherteil 15 besteht aus RAM usw. und enthält einen Speicherbereich mit variablen Adressen 15a als Arbeitsbereich zum Speichern oder Erzeugen von Java-Objekten und einen Speicherbereich mit festen Adressen 15b als Arbeitsbereich für das native Programm 13 oder das OS 14.
Der Speicherbereich mit variablen Adressen 15a dient als Funktion zum Sammeln von Java-Objekt, das von Java VM 12 nicht benötigt wird (im folgenden „GC-Funktion" (Müllabfuhrfunktion) und die Adressen gespeicherter Daten sind variabel und steuerbar. Die Speicherbereiche, die nicht mehr benutzt werden, werden von der GC-Funktion gesammelt, um zusammenhängenden benutzbaren Speicherbereich anzubieten, wodurch der Speicher effizient benutzt werden kann. Andererseits werden in dem Speicherbereich mit festen Adressen 15b Daten gespeichert, die für die Ausführung von Modulen wie zum Beispiel dem nativen Programm 13 und dem OS 14 verwendet werden, und unter der Verwaltung des OS 14 wird jedem Programm eine Adresse zugeteilt. Daten werden nicht wie in dem Speicherbereich mit variablen Adressen 15a an eine andere Stelle gebracht.
Wie oben dargelegt werden unter der Speicherverwaltung in der Ausführungsumgebung der Java-Anwendung 11 Java-Objekte im allgemeinen in dem Speicherbereich mit variablen Adressen 15a auf dem Speicher gespeichert, um die GC-Funktion der Java VM 12 zu benutzen. Dieser Bereich wird von dem Bereich, in dem durch das native Programm 13 und das OS 14 zu benutzende Daten gespeichert werden, unterschieden.
Das native Programm 13 ist ein in der C-Sprache beschriebener nativer Code. Das native Programm 13 besteht aus einem Modul, das Echtzeitverarbeitung ermöglicht, um Bilddaten über Kommunikationsmedien wie zum Beispiel das Internet, Satellitenrundsendung, Kabelrundsendung usw. gemäß einer Anforderung aus der Java-Anwendung 11 in den Speicherbereich mit festen Adressen 15b herunterzuladen.
Als nächstes wird der Verarbeitungsfluß, wenn heruntergeladene Bilddaten zur Ausführung der Java-Anwendung 11 benutzt werden, erläutert. Da sich die Java-Anwendung 11 nur auf ein in dem Speicherbereich mit variablen Adressen 15a gespeichertes Java-Objekt beziehen kann, kann man sich hier nicht direkt als Java-Objekt auf die heruntergeladenen Bilddaten beziehen.
In 10 werden die Java-Objekte OBA, OBB in dem Speicherbereich mit variablen Adressen 15a des Objektspeicherteils 15 gespeichert. In dem Speicherbereich mit festen Adressen 15b werden durch das native Programm 13 heruntergeladene Daten DA gespeichert. Bei dem in 10 gezeigten Beispiel kann sich die Java-Anwendung 11 nur auf die Java-Objekte OBA, OBB beziehen, und auf die heruntergeladenen Daten DA kann man sich nicht beziehen.
11 ist ein Diagramm des Zustands des Objektspeicherteils 15, wenn der Bezug auf die Herunterladedaten DA als ein Java-Objekt möglich ist. Gemäß einer Anforderung aus der Java-Anwendung 11 sichert der Objektverwaltungsteil 12b zunächst einen Speicherbereich in einem freien Bereich gemäß den Herunterladedaten DA.
Als nächstes kopiert das native Programm 13 die Herunterladedaten DA in dem Speicherbereich mit festen Adressen 15b über den JNI-Teil 12c auf den Speicherbereich mit variablen Adressen 15a als Herunterladedaten DB. Die in den Speicherbereich mit variablen Adressen 15a kopierten Herunterladedaten DB werden schließlich bei der Ausführung der Java-Anwendung 11 als Java-Objekt verwendet.
Wenn, wie oben erwähnt, durch das native Programm 13 verwaltete Daten im Speicherbereich mit festen Adressen 15b bei der Ausführung der Java-Anwendung 11 verwendet werden, ist es notwendig, die Herunterladedaten DA aus dem Speicherbereich mit festen Adressen 15b in den Speicherbereich mit variablen Adressen 15a zu kopieren. Aufgrund des Kopierens entsteht deshalb Overhead und die Ausführung könnte verzögert werden. Zusätzlich ist es während des Kopierens notwendig, einen Speicherbereich der Herunterladedaten DA für das Kopierziel oder den Speicherbereich mit variablen Adressen 15a bzw. die Kopierquelle oder den Speicherbereich mit festen Adressen 15b zu sichern, und es zeigt sich, daß der Speicherbereich nicht effizient verwendet wird.
Der Stand der Technik der vorliegenden Erfindung umfaßt u. a. die folgenden Dokumente:
D1: KENNETH B RUSSELL: 'Re: Inter process communication' [Online] 6. November 1998 (1998-11-06) XP002192816 info-Performer@sgi.com Abgerufen vom Internet: <URL: ttp://oss.sgi.com/projects/performer/mail/infoperformer/perf-98-11/0042.html> [abgerufen am 2002-03-12]
D2 US-A-S 873 105 (HELLER STEVEN ET AL) 16. Februar 1999 (1999-02-16)
D3 'SAS/C Software, Changes and Enhancements' [Online] März 1998 (1998-03), SAS INSTITUTE INC., CARY, NC XP002192817 ISBN: 1-58025-135-8 abgerufen aus dem Internet: <URL: http://www.sas.com/service/library/onlinedoc/sasc/ doc650/changes.pdf> [abgerufen am 2002-03-12]
Aus D1 ist die Verwendung eines gemeinsam benutzten Speichers für die Kommunikation zwischen Prozessen in einer objektorientierten Programmiersprache (C++) bekannt, die erwähnten Bibliotheksroutinen shmat und shmget erzeugen einen gemeinsam benutzten Speicher und greifen auf diesen zu (siehe D3, das durch eindeutige Bezugnahme als in die Lehren von D1 integriert betrachtet werden sollte), und zwar an einer unmutable-Adresse (Rückgabewert der shmat-Routine, siehe D3).
D1 sagt aus, daß ein Durchführer- und ein anderer Prozeß nichts miteinander zu tun haben und es wird daher die Verwendung der für jede der beiden Aufgaben am besten geeigneten Programmiersprache nahegelegt.
Eine objektorientierte Programmiersprache, die Plattformunabhängigkeit durch eine virtuelle Maschine erzielt, die eine umordnende Müllabfuhr bereitstellt (Java) ist aus D2 bekannt.
Eine Aufgabe der vorliegenden Erfindung ist folglich die Durchführung der Speicherverwaltung dergestalt, daß Overhead beim Kopieren vermieden wird und eine effizientere Verwendung des Speicherbereichs erfolgt.
Die Erfindung betrifft eine Vorrichtung, ein Verfahren, ein Programm und ein computerlesbares Speichermedium gemäß den angefügten Ansprüchen.
Es werden nun die Ausführungsformen der vorliegenden Erfindung anhand der beigefügten Zeichnungen beschrieben. Es zeigen:
1 ein Funktionsblockschaltbild einer Konfigurationsskizze einer Speicherverwaltungsvorrichtung gemäß Ausführungsform 1 der vorliegenden Erfindung;
2 ein Diagramm einer in einer Objekttabelle gespeicherten Datenkonfiguration, eines Objektverwaltungsinformationsspeicherteils und eines Objektspeicherteils gemäß Ausführungsform 1;
3 ein Diagramm eines Zustands von erzeugten Java-Objektverwaltungsinformationen an Herunterladedaten gemäß Ausführungsform 1;
4 ein Diagramm des Prozeßflusses vom Empfangen heruntergeladener Daten bis zum Auslesen heruntergeladener Daten als Java-Objekt gemäß Ausführungsform 1;
5 ein Flußdiagramm des Flusses der Java-Objekterzeugung gemäß Ausführungsform 1;
6 ein Funktionsblockschaltbild einer groben Konfiguration einer Speicherverwaltungsvorrichtung gemäß Ausführungsform 2;
7 ein Flußdiagramm des Verarbeitungsflusses zum Löschen von unbenötigtem Java-Objekt in dem Objektspeicherteil gemäß Ausführungsform 2;
8 ein Funktionsblockschaltbild einer groben Konfiguration einer Speicherverwaltungsvorrichtung gemäß Ausführungsform 3;
9 ein Flußdiagramm des Flusses der Java-Objekterzeugung gemäß Ausführungsform 3;
10 ein Funktionsblockschaltbild einer herkömmlichen Speicherverwaltungsvorrichtung zum Herunterladen von Bilddaten im Stand der Technik;
und 11 ein Diagramm des Zustands des Objektspeicherteils, wenn der Bezug auf heruntergeladene Daten als Java-Objekt möglich ist.
Wie in 1 gezeigt, ist die Speicherverwaltungsvorrichtung 100 mit folgendem ausgestattet: Java-Anwendungsspeicherteil 101, Java VM 102, Java-Objekttabelle 103, Java-Objektverwaltungsinformationsspeicherteil 104, Objektspeicherteil 105, Herunterladeverwaltungsteil 106, Netzwerksteuerteil 107, Netzwerkeinrichtung 108 und Festadressenspeicherbereitstellungsteil 109 als Beispiel.
Der Java-Anwendungsspeicherteil 101 speichert die Java-Anwendung 111 und die Klassenbibliothek 112. Die Java-Anwendung 111 besteht aus einem in der objektorientierten Sprache Java beschriebenen Programm. Der Quellcode der Java-Anwendung 111 wird kompiliert und in einen Bytecode umgesetzt. Dieser Bytecode wird zu der Java VM 102 gesendet. Die Klassenbibliothek 112 ist eine Bibliothek, in der Klassen gesammelt werden, in denen die Datenstruktur in dem Java-Objekt durch das Ganze definiert werden. Der Java-Anwendungsspeicherteil 101 gemäß der vorliegenden Ausführungsform, der aus Direktzugriffsspeicher (RAM) besteht, kann mit Nur-Lese-Speicher (ROM), Festplatte usw. materialisiert werden.
Die Java VM 102 ist mit folgendem ausgestattet: Java-Interpretiererteil 102a, Java-Objektbezugsteil 102b, Java-Objekterzeugungsteil für den Speicherbereich mit variablen Adressen (im folgenden „GOBV-Teil") 102c und Java-Objekterzeugungsteil für Speicherbereich mit festen Adressen („GOBF-Teil") 102d als Beispiel.
Der Java-Interpretiererteil 102a liest einzeln Anweisungen aus der Java-Anwendung 111 aus, interpretiert jede Anweisung und führt sie aus. Diese Speicherverwaltungsvorrichtung 100 verwendet den Ausführungsmechanismus des Interpretierers, kann aber ordnungsgemäß auf Ausführungsmechanismen wie zum Beispiel einen Kompiler umgeschaltet werden. Der Java-Objektbezugsteil 102b materialisiert das Herauslesen eines bereits erzeugten Java-Objekts gemäß einer Anforderung von der Java-Anwendung 111. Der GOBV-Teil 102c und der GOBF-Teil 102d erzeugen Java-Objekte in dem Objektspeicherteil 105 gemäß einer Anforderung von der Java-Anwendung 111.
Die Java-Objekttabelle 103 speichert Zeiger, die auf Adressen der Java-Objektverwaltungsinformationen zeigen. Der Java-Objektverwaltungsinformationsspeicherteil speichert Java-Objektverwaltungsinformationen. Java-Objektverwaltungsinformationen sind Informationen zur Verwaltung des Java-Objekts in dem Objektspeicherteil 105 und Daten bezüglich der Klasse seines Java-Objekts. Zu Informationen bezüglich des Java-Objekts gehören: Datengröße, auf die Adressen von Java-Objekten in dem Objektspeicherteil 105 zeigende Zeiger als Beispiel. Informationen bezüglich der Klasse sind notwendige Informationen für die Ausführung oder Bezugnahme durch Java-Anwendung 111, wie zum Beispiel ein Klassenname, der den Typ von Java-Objekt, Ausführungscode usw. angibt.
Der Objektspeicherteil 105 besteht aus RAM usw. Der Objektspeicherbereich 105 ist mit dem Speicherbereich mit variablen Adressen 105a als Arbeitsbereich zur Erzeugung eines Java-Objekts und dem Speicherbereich mit festen Adressen 105b, in dem durch das OS oder andere Anwendungen (nicht gezeigt) verwaltete Daten gespeichert werden, ausgestattet.
In dem Speicherbereich mit variablen Adressen 105a wird ein Java-Objekt durch den GOBV-Teil 102c der Java VM 102 erzeugt. Die Adresse des gespeicherten Java-Objekts, die in der GC-Funktion der Java VM 102 verwendet wird, ist variabel und steuerbar.
In der Zwischenzeit speichert der Speicherbereich mit festen Adressen 105b unter der Verwaltung des OS (nicht gezeigt) durch jedes Programm erzeugte Daten. Und die GC-Funktion der Java VM 102 führt keine Umordnung von Daten durch, wie in dem Speicherbereich mit variablen Adressen 105a.
Der Herunterladeverwaltungsteil 106 wird durch ein Programm materialisiert, das sowohl in nativer Sprache, wie der C-Sprache, die nativen Code abhängig von der Plattform erzeugt, als auch der Java-Sprache materialisiert wird, und führt eine Speicherverwaltung in dem Speicherbereich mit festen Adressen 105b von über das Internet 300 empfangenen Daten aus.
Der Netzwerksteuerteil 107 steuert die Netzwerkeinrichtung 108, die aus einem Modem, einem Endgeräteadapter (TA) usw. besteht und empfängt Daten aus dem Internet 300. Der Netzwerksteuerteil 107 erfordert Echtzeitverarbeitung und wird durch ein aus einer nativen Sprache wie zum Beispiel der C-Sprache gebildetes Programm materialisiert.
Wenn Daten gemäß einer Anforderung der Java-Anwendung 111 empfangen werden, bietet der Festadressenspeicherbereitstellungsteil 109 dem Herunterladeverwaltungsteil 106 einen Speicherbereich zum Speichern empfangener Daten aus einem freien Bereich des Speicherbereichs mit festen Adressen 105b an.
Der die (nicht gezeigte) zentrale Verarbeitungseinheit (CPU) enthaltende Steuerteil materialisiert durch die Speicherverwaltungsvorrichtung 100 auszuführende Steuermaßnahmen in Zusammenwirkung mit den von der CPU verschiedenen Schaltungen gemäß dem Programm der vorliegenden Erfindung. Der Einfachheit halber erfolgt die folgende Beschreibung unter der Annahme, daß Steuermaßnahmen, an denen die CPU beteiligt ist, direkt durch Programme, wie zum Beispiel Java-Anwendungen gesteuert werden.
Als nächstes wird die Datenausbildung von Java-Objektsteuerung in der Speicherverwaltungsvorrichtung 100 mit Bezug auf die Zeichnungen beschrieben. 2 ist ein Diagramm einer Datenkonfiguration, die in der Java-Objekttabelle 103, dem Java-Objektverwaltungsinformationsspeicherteil 104 und dem Objektspeicherteil 105 gespeichert ist.
In 2 ist OB1 ein durch den GOBV-Teil 102c in dem Speicherbereich mit variablen Adressen 105a erzeugtes Java-Objekt. OM1 sind Java-Objektverwaltungsinformationen des Java-Objekts OB1. Zu diesen Java-Objektinformationen gehören Klasseninformationen und ein Zeiger, der auf die Adresse des Java-Objekts OB1 in dem Speicherbereich mit variablen Adressen 105a zeigt. P1 ist ein Zeiger, der auf die Adresse in dem Java-Objektverwaltungsinformationsspeicherteil 104 der Java-Objektverwaltungsinformationen OM1 zeigt. Durch Bezugnahme auf den Zeiger P1 und die Java-Objektverwaltungsinformation OM1 kann die Java-Anwendung 111 das Java-Objekt OB1 über den Java-Objektbezugsteil 102b auslesen und diesen zur Ausführung der Java-Anwendung verwenden.
Ähnlich ist OB2 ein durch den GOBV-Teil 102c in dem Speicherbereich mit variablen Adressen 105a erzeugtes Java-Objekt. OM2 sind Java-Objektverwaltungsinformationen des Java-Objekts OB2. Diese Java-Objektverwaltungsinformationen enthalten Klasseninformationen und einen Zeiger, der auf die Adresse des Java-Objekts Java-Objekt OB2 in dem Speicherbereich mit variablen Adressen 105a zeigt. P2 ist ein Zeiger, der auf die Adresse in dem Java-Objektverwaltungsinformationsspeicherteil 104 der Java-Objektverwaltungsinformationen OM2 zeigt. Durch Bezugnahme auf den Zeiger P2 und die Java-Objektverwaltungsinformationen OM2 kann die Java-Anwendung 111 das Java-Objekt OB2 über den Java-Objektbezugsteil 102b lesen und diesen zur Ausführung der Java-Anwendung verwenden.
D1 gibt Daten an, die durch den Herunterladeverwaltungsteil 106 aus dem Internet 300 in den Speicherbereich mit festen Adressen 105b heruntergeladen werden. Hier in dieser Speicherverwaltungsvorrichtung 100 können Daten, die durch ein von der Java-Anwendung verschiedenes natives Programm, wie zum Beispiel den Herunterladeverwaltungsteil 106, in dem Speicherbereich mit festen Adressen 105b erzeugt werden, gemäß einer Anforderung der Java-Anwendung 111 als Java-Objekt ausgelesen werden. In dem in 2 gezeigten Beispiel erzeugt der GOBF-Teil 102d Java-Objektverwaltungsinformationen zum Auslesen von Herunterladedaten D1. Aus diesem Grund können die in dem Speicherbereich mit festen Adressen 105b aus dem Internet 300 empfangenen Herunterladedaten D1 ohne Kopieren in den Speicherbereich mit variablen Adressen 105a als Java-Objekt ausgelesen werden.
3 ist ein Diagramm des Zustands erzeugter Java-Objektverwaltungsinformationen der Herunterladedaten D1 (siehe 2). OMD sind Java-Objektverwaltungsinformationen, die Klasseninformationen und einen auf die Adresse der Herunterladedaten D1 in dem Speicherbereich mit festen Adressen zeigenden Zeiger enthalten. PD ist ein Zeiger, der auf die Adresse der Java-Objektverwaltungsinformationen OMD in dem Java-Objektverwaltungsinformationsspeicherteil 104 zeigt. Durch Bezugnahme auf den Zeiger PD und die Java-Objektverwaltungsinformationen OMD kann die Java-Anwendung 111 die Herunterladedaten D1 über den Java-Objektbezugsteil 102b als Java-Objekt auslesen und kann diese zur Ausführung der Java-Anwendung verwenden.
Nun wird der Verarbeitungsfluß vom Herunterladen der Herunterladedaten D1 bis zum Auslesen der heruntergeladenen Daten als Java-Objekt in der Speicherverwaltungsvorrichtung 100 gemäß der vorliegenden Ausführungsform erläutert. 4 ist ein Diagramm des Flusses vom Empfangen der Herunterladedaten D1 bis zum Auslesen der heruntergeladenen Daten als Java-Objekt.
Die Java-Anwendung 111 gibt eine Empfangsanforderung durch die Java VM 102 an den Herunterladeverwaltungsteil 106 aus durch Spezifizieren von Identifikationsinformationen an herunterzuladenden Daten (Schritt S1). Als Identifikationsinformationen an herunterzuladenden Daten sind Identifikationsnummern von Daten und ihr Speicherort (URL – Uniform Resource Locator) zu spezifizieren.
Dann gibt der Herunterladeverwaltungsteil 106 eine Herunterladeanforderung an den Netzwerksteuerteil 107 aus durch Spezifizieren der Identifikationsnummer herunterzuladender Daten und der Adresse, an der die Daten in dem Speicherbereich mit festen Adressen 105b gespeichert sind (Schritt S2). Der Netzwerksteuerteil 107 stellt über die Netzwerkeinrichtung 108 eine Verbindung mit dem im Schritt S1 spezifizierten Datenspeicherort im Internet 300 her und lädt die spezifizierten Daten herunter. Die als Herunterladedaten D1 heruntergeladenen Daten (siehe 2) werden an der im Schritt S2 spezifizierten Adresse im Speicherbereich mit festen Adressen 105b gespeichert (Schritt S3).
Nachdem das Herunterladen der Herunterladedaten D1 vorüber ist, informiert der Netzwerksteuerteil 107 den Herunterladeverwaltungsteil 106, daß das Herunterladen abgeschlossen ist (Schritt S4). Nachdem das Herunterladen vorüber ist, wird die Erzeugung des Java-Objekts, die später beschrieben wird, durch die Java VM 102 auf der Grundlage der Herunterladedaten D1 ausgeführt (Schritt S5). Nachdem die Java-Objekterzeugungsverarbeitung im Schritt S5 Java-Objektverwaltungsinformationen OMD erzeugt hat, liest die Java-Anwendung 111 die Herunterladedaten D1 als Java-Objekt aus und verwendet die zur Ausführung der Java-Anwendung (Schritt S6).
Als nächstes wird der Verarbeitungsfluß der Java-Objekterzeugung (Schritt S5) beschrieben. 5 ist ein Flußdiagramm des Flusses der Java-Objekterzeugung (Schritt S5).
Der Herunterladeverwaltungsteil 106 fordert den GOBF-Teil 102d auf, auf der Grundlage der Herunterladedaten D1 ein Java-Objekt zu erzeugen, durch Spezifizieren der Herunterladedaten D1 in dem Speicherbereich mit festen Adressen 105b (Schritt S11). Dann wird beurteilt, ob die Adresse, an die Herunterladedaten D1 in dem Speicherbereich mit festen Adressen 105b gespeichert sind, spezifiziert ist (Schritt S12). Wenn die Adresse nicht spezifiziert ist (Schritt S12; Nein), wird ein Speicherbereich für ein spezifisches Volumen in dem Speicherbereich mit festen Adressen 105b durch den Festadressenspeicherbereitstellungsteil 109 bereitgestellt (Schritt S13). Da die Adresse der Herunterladedaten D1 bereits im Schritt S2 durch den Herunterladeverwaltungsteil 106 spezifiziert wird, wird im Fall von 2 die Verarbeitung im Schritt S13 nicht ausgeführt, und der Prozeß schreitet zum Schritt S14 voran.
Wenn die Adresse der in Java-Objekt umzusetzenden Herunterladedaten D1 spezifiziert ist (Schritt S12; Ja), werden über die Java VM 102 dem zu erzeugenden Java-Objekt entsprechende Klasseninformationen aus der Klassenbibliothek 112 ausgelesen und als Java-Objektverwaltungsinformationen OMD des Java-Objektverwaltungsinformationsspeicherteils 104 gespeichert (Schritt S14).
Ein Speicherbereich, in dem ein auf die Adresse der Herunterladedaten D1 zeigender Zeiger als Java-Objektverwaltungsinformationen OMD gespeichert ist, wird in dem Java-Objektverwaltungsinformationsspeicherteil 104 gesichert (Schritt S15). Der auf die Adresse der Herunterladedaten D1 in dem Speicherbereich mit festen Adressen 105b zeigende Zeiger wird als Java-Objektverwaltungsinformationen OMD in dem gesicherten Speicherbereich gespeichert (Schritt S16).
Dann wird auf der auf die Adresse der Java-Objektverwaltungsinformationen OMD zeigenden Zeiger PD in der Java-Objekttabelle gespeichert (Schritt S17). Danach werden die Herunterladedaten D1 durch den Herunterladeverwaltungsteil 106 an die Java-Anwendung 111 abgeliefert. Weiterhin werden Herunterladedaten D1 durch den Java-Objektbezugsteil 102b gemäß Java-Objektverwaltungsinformationen OMD ausgelesen und bei der Ausführung der Java-Anwendung 111 verwendet (Schritt S6 in 4).
Wie beschrieben, können in dem Speicherbereich mit festen Adressen 105b erzeugte heruntergeladene Daten direkt als Java-Objekt ausgelesen werden, und deshalb wird das Kopieren heruntergeladener Daten in den Speicherbereich mit variablen Adressen 105a nicht benötigt und das Verarbeitungsoverhead wird beseitigt und die Verarbeitungslast der Speicherverwaltungs vorrichtung verringert.
Während des Kopierens ist es außerdem nicht notwendig, zwei Speicherbereiche in dem Speicherbereich mit variablen Adressen 105a bzw. dem Speicherbereich mit festen Adressen 105b zu sichern, um Java-Objekte zu erzeugen, wodurch der Speicherbereich effizient benutzt werden kann. Dies ist besonders nützlich, wenn ein großes Datenvolumen, wie zum Beispiel Klang- und Bilddaten, heruntergeladen wird und ein Bezug darauf in der Java-Anwendung 111 hergestellt wird. Der Grund dafür besteht darin, daß es, wenn ein großes Datenvolumen empfangen wird, nicht notwendig sein wird, sowohl für den Speicherbereich mit variablen Adressen 105a als auch den Speicherbereich mit festen Adressen 105b einen großvolumigen Speicherbereich zu sichern. Es muß nicht gesagt werden, daß die vorliegende Erfindung auch beim Herunterladen eines Quellcodes angewandt werden kann.
Nachdem das Herunterladen vorüber ist (Schritt S3) werden in 4 Java-Objektverwaltungsinformationen der heruntergeladenen Daten erzeugt (Schritt S5) und der Bezug auf die heruntergeladenen Daten kann direkt von der Java-Anwendung 111 aus erfolgen, aber die Verarbeitungsprozedur kann verändert werden, um die Effizienz der Echtzeitverarbeitung weiter zu verbessern. Auch wenn das Herunterladen von Daten nicht abgeschlossen ist, kann genauer gesagt der Bezug auf Daten, die noch heruntergeladen werden, von der Java-Anwendung 111 aus erfolgen.
Nachdem Identifikationsinformationen von herunterzuladenden Daten durch die Java-Anwendung 111 spezifiziert werden (Schritt S1) werden zum Beispiel in 4 Java-Objektverwaltungsinformationen durch Erzeugung des Java-Objekts im Schritt S5 im voraus erzeugt. Dadurch können gerade heruntergeladene Daten direkt als Java-Objekt ausgelesen werden. Folglich kann die Effizienz der Echtzeitverarbeitung im Vergleich mit der herkömmlichen Technik, die einem Kopieren aus dem Speicherbereich mit festen Adressen 105b in den Speicherbereich mit variablen Adressen 105a unterzogen wird, weiter verbessert werden. In diesem Fall wird bei der Java-Objekterzeugungsverarbeitung in 5 die Adresse des Speicherbereichs mit festen Adressen 105b nicht spezifiziert (Schritt S12 in 5; Nein), und deshalb wird ein Speicherbereich in dem Speicherbereich mit festen Adressen 105b durch den Festadressenspeicherbereitstellungsteil 109 bereitgestellt (Schritt S13 in 5).
Ausführungsform 2 der vorliegenden Erfindung wird ausführlich unter Bezugnahme auf die Zeichnungen erläutert. In der Speicherverwaltungsvorrichtung gemäß der vorliegenden Ausführungsform werden Daten des Speicherbereichs mit festen Adressen 105b gemäß Java-Objektverwaltungsinformationen wie in der Speicherverwaltungsvorrichtung 100 gemäß Ausführungsform 1 ausgelesen. Wenn die Ausführung der Java-Anwendung vorüber ist und Daten des Speicherbereichs mit festen Adressen 105b nicht mehr benötigt werden, werden außerdem unbenötigte Daten aus dem Speicherbereich mit festen Adressen gelöscht. Da unbenötigte Daten des Speicherbereichs mit festen Adressen 105b gelöscht werden, kann ein freier Bereich effektiv als natives Programm oder OS-Arbeitsbereich gesichert werden.
6 ist ein Funktionsblockschaltbild einer groben Konfiguration der Speicherverwaltungsvorrichtung 200 gemäß Ausführungsform 2 der vorliegenden Erfindung. Die Speicherverwaltungsvorrichtung 200 gemäß der vorliegenden Ausführungsform ist mit folgendem ausgestattet: Java-Anwendungsspeicherteil 101, Java VM 202, Java-Objekttabelle 103, Java-Objektverwaltungsinformationsspeicherteil 104, Objektspeicherteil 105, Herunterladeverwaltungsteil 106, Netzwerksteuerteil 107, Netzwerkeinrichtung 108, Festadressenspeicher bereitstellungsteil 109 als Beispiel. Der Java-Anwendungsspeicherteil 101, die Java-Objekttabelle 103, der Java-Objektverwaltungsinformationsspeicherteil 104, der Objektspeicherteil 105, der Herunterladeverwaltungsteil 106, der Netzwerksteuerteil 107, die Netzwerkeinrichtung 108 und der Festadressenspeicherbereitstellungsteil 109 sind in bezug auf grundlegende Konfiguration und Funktion mit denen von Ausführungsform 1 identisch und Einzelheiten der jeweiligen Teile werden nicht erläutert.
Konfigurationsunterschiede zwischen der Speicherverwaltungsvorrichtung 200 gemäß der vorliegenden Ausführungsform und der Speicherverwaltungsvorrichtung 100 gemäß Ausführungsform 1 bestehen darin, daß die Java VM 202 weiterhin einen Müllverarbeitungsteil 202a umfaßt.
Der Müllverarbeitungsteil 202a ist mit folgendem ausgestattet: Bezugswiderrufsobjektdetektionsteil 203, Objektartbeurteilungsteil 204, Löschteil 205 für Speicher mit variablen Adressen, Löschungsbeurteilungsteil 206 für Speicher mit festen Adressen und Löschteil 207 für Speicher mit festen Adressen als Beispiel. Der Müllverarbeitungsteil 202a materialisiert eine Funktion des Löschens von unbenötigten Java-Objekten, die in dem Speicherbereich 105a mit variablen Adressen und dem Speicherbereich mit festen Adressen 105b gespeichert sind, gemäß einer Anforderung von der Java-Anwendung 111 und dem Herunterladeverwaltungsteil 106.
Der Bezugswiderrufsobjektdetektionsteil 203 erkennt unbenötigte Objekte, auf die sich die Java-Anwendung 111 nicht bezieht, unter den in dem Objektspeicherteil 105 gespeicherten Java-Objekten.
Der Java-Objektartbeurteilungsteil 204 beurteilt, wo das von dem Bezugswiderrufsobjektdetektionsteil 203 erkannte unbenötigte Java-Objekt gespeichert ist, in dem Speicherbereich mit variablen Adressen 5a oder dem Speicherbereich mit festen Adressen 105b.
Der Löschteil 205 für den Speicher mit variablen Adressen löscht unbenötigte Java-Objekte, die in dem Speicherbereich mit variablen Adressen 105 gespeichert sind.
Der Löschungsbeurteilungsteil 206 für Speicher mit festen Adressen beurteilt, ob der Java-Objektartbeurteilungsteil 204 urteilt, daß dem unbenötigten Java-Objekt entsprechende Daten in dem Speicherbereich mit festen Adressen 105b vorliegen, und beurteilt, ob eine Anforderung aus dem Herunterladeverwaltungsteil 106 zur Löschung von Daten entsprechend dem unbenötigten Java-Objekt vorliegt.
Der Löschteil 207 für Speicher mit festen Adressen löscht Daten entsprechend dem in dem Speicherbereich mit festen Adressen 105b gespeicherten unbenötigten Java-Objekt gemäß den Beurteilungsergebnissen des Löschungsbeurteilungsteils 206 für Speicher mit festen Adressen.
Nun wird der Verarbeitungsfluß des Löschens unbenötigter Java-Objekte in dem Objektspeicherteil 105 erläutert. 7 ist ein Flußdiagramm des Flusses des Löschens unbenötigter Java-Objekte in dem Objektspeicherteil 105.
Nachdem die Ausführung der Java-Anwendung 111 vorüber ist, wird zunächst der Bezug auf Java-Objekte in dem Objektspeicherteil 105 entfernt (Schritt S21). Danach wird eine Anforderung zum Löschen unbenötigter Java-Objekte, deren Bezüge entfernt werden, aus der Java-Anwendung 111 an die Java VM 202 ausgegeben (Schritt S 22).
Als nächstes erkennt der Bezugswiderrufsobjekt detektionsteil 203 der Java VM 202 das Java-Objekt, von dem die Löschung angefordert wird. Der Java-Objektartbeurteilungsteil 204 beurteilt, wozu das erkannte Java-Objekt gehört, dem Speicherbereich mit variablen Adressen 105a oder dem Speicherbereich mit festen Adressen 105b (Schritt S23). Wenn das erkannte Java-Objekt zu dem Speicherbereich mit variablen Adressen 105a gehört, wird das von dem Löschteil 205 für Speicher mit variablen Adressen erkannte Java-Objekt gelöscht.
Wenn im Schritt S23 beurteilt wird, daß das Java-Objekt, dessen Löschung angefordert wird, auf Daten basiert, die in dem Speicherbereich mit festen Adressen 105b gespeichert sind, wird eine Anforderung zum Löschen von dem Java-Objekt entsprechende Daten durch den Löschungsbeurteilungsteil 206 für Speicher mit festen Adressen gespeichert (Schritt S204).
Danach gibt der Herunterladeverwaltungsteil 106 eine Anforderung zum Löschen von Daten aus, wofür die Löschungsanforderung aus dem Java-Objektartbeurteilungsteil 204 im Schritt S24 gespeichert wird (Schritt S25). Wenn eine Löschungsanforderung von dem Herunterladeverwaltungsteil 106 ausgegeben wird, gibt der Löschungsbeurteilungsteil 206 für Speicher mit festen Adressen an den Löschteil 207 für Speicher mit festen Adressen eine Anforderung zum Löschen von Daten aus, wofür die Löschungsanforderung im Schritt S24 gespeichert wird. Es erfolgt keine Löschungsanforderung durch den Herunterladeverwaltungsteil 106, der Löschungsbeurteilungsteil 206 für Speicher mit festen Adressen gibt keine Löschungsanforderung an den Löschteil 207 für Speicher mit festen Adressen aus.
Anders ausgedrückt: nur wenn sowohl eine Löschungsanforderung von der Java-Anwendung 111 als eine Löschungsanforderung von dem Herunterladeverwaltungsteil 106 ausgegeben werden, werden die unbenötigten Daten in dem Speicherbereich mit festen Adressen 105b durch den Löschteil 207 für Speicher mit festen Adressen gelöscht. Das heißt, nur wenn aus keine der Anwendungen in der Speicherverwaltungsvorrichtung 200 ein Bezug erfolgt, werden unbenötigte Daten gelöscht und deshalb kann das Fallenlassen von Daten in ausführenden Anwendungen vermieden werden und die Kommunisierung des Speichers kann sicher materialisiert werden.
Es kann entweder eine Löschungsanforderung von der Java-Anwendung 111 oder eine Löschungsanforderung von dem Herunterladeverwaltungsteil 106 zuerst kommen.
Als nächstes löscht der Löschteil 207 für Speicher mit festen Adressen einen Zeiger in der Java-Objekttabelle 103 entsprechend Daten, ein Objekt zur Löschung und in dem Java-Objektverwaltungsinformationsteil 104 gespeicherte Java-Objektverwaltungsinformationen (Schritt S26).
Außerdem fordert der Löschteil 207 für Speicher mit festen Adressen von dem Festadressenspeicherbereitstellungsteil 109 an, den Speicherbereich in dem Speicherbereich mit festen Adressen 105b, in dem ein Objekt zur Löschung gespeichert ist, freizugeben (Schritt S27). Nachdem eine Löschungsanforderung empfangen wird, löscht der Festadressenspeicherbereitstellungsteil 109 Daten, ein Objekt zur Löschung und befreit den Speicher (Schritt S28).
Wie oben dargelegt, werden unbenötigte Daten in dem Speicherbereich mit festen Adressen 105b nur dann gelöscht, wenn kein Bezug von irgendwelchen der Anwendungen in der Speicherverwaltungsvorrichtung 200 erfolgt, und deshalb kann das Fallenlassen von Daten in ausführenden Anwendungen vermieden werden und die Kommunisierung des Speichers kann sicher materialisiert werden.
Damit die Java-Anwendung 111 in dem Speicherbereich mit festen Adressen 105b durch das native Programm erzeugte Daten ausliest, werden in Ausführungsform 1 ihre Datenverwaltungsinformationen durch den GOBF-Teil 102d erzeugt.
Es ist aber nicht notwendig, daß der GOBF-Teil 102d Verwaltungsinformationen für alle durch das native Programm in dem Speicherbereich mit festen Adressen 105b erzeugte Daten erzeugt. Es wird nicht bevorzugt, daß Daten in dem Speicherbereich mit festen Adressen 105b gemäß Spezifikation oder Funktion des OS zur Verwaltung des Speicherbereichs mit festen Adressen 105b und der Vorrichtung als Java-Objekt behandelt werden.
Wenn zum Beispiel durch das native Programm in 105b erzeugte Daten klein sind, und sogar, wenn ihr Daten-Java-Objekt in dem Speicherbereich mit variablen Adressen 105a erzeugt wird, ist die Häufigkeit des an eine andere Stelle Bringens durch die GC-Funktion gering, das Verarbeitungsoverhead und die Verringerung der Speichereffizienz treten kaum auf. Dadurch ist der Endnutzen durch ihre Verarbeitung relativ gering. Wenn das OS zur Verwaltung des Speicherbereichs mit festen Adressen 105b keine GC-Funktion aufweist und kleinvolumige Daten in dem Speicherbereich mit festen Adressen 105b als Java-Objekt behandelt werden, bewirken die kleinvolumigen Daten eine Fragmentierung in dem Speicherbereich mit festen Adressen 105b.
Wenn im Fall großvolumiger Daten, wie zum Beispiel Klang-, Bilddaten, zwischenzeitlich ihr Daten-Java-Objekt in dem Speicherbereich mit variablen Adressen 105a erzeugt wird, werden wie bereits erwähnt die Verringerung des Overheads und die Speichereffizienz groß sein. Wenn der Speicherbereich mit variablen Adressen 105a durch großvolumige Daten komprimiert wird, werden Java-Objekte durch die GC-Funktion außerdem nur selten an eine andere Stelle gebracht und die Last des Systems wird groß sein. Auch wenn der Speicherbereich mit festen Adressen 105b klein ist, sind, wenn eine Gültigkeitslaufzeit von Daten kurz ist, diese Endnutzen größer als der Endnutzen, das der Speicherbereich mit festen Adressen komprimiert wird. Wenn der Speicherbereich mit festen Adressen 105a jedoch klein ist und eine Gültigkeit großvolumiger Daten lang ist, ist es bevorzugt, daß das Java-Objekt von Daten in dem Speicherbereich mit variablen Adressen 105a erzeugt wird.
Wie in 8 gezeigt, enthält deshalb die Speicherverwaltungsvorrichtung 400 gemäß dieser Ausführungsform 3 zusätzlich zu der Konfiguration der Speicherverwaltungsvorrichtung 100 gemäß Ausführungsform 1 den Beurteilungsteil 401.
Der Beurteilungsteil 401 beurteilt gemäß in dem Speicherbereich mit festen Adressen 105b gespeicherten Daten, ob das Java-Objekt der Daten in dem Speicherbereich mit variablen Adressen 105a gespeichert ist.
Diese Beurteilung geschieht auf der Grundlage der Datengröße, -art, Gültigkeitslaufzeit usw. Diese Basen werden gemäß Größe von Gesamtspeicher, seiner Einzelheiten (jede Größe des Speicherbereichs mit variablen Adressen 105a und des Speicherbereichs mit festen Adressen 105b), der Größe oder Behandlung von herunterzuladenden Daten, der Funktion des OS zur Verwaltung des Speicherbereichs mit festen Adressen oder dergleichen bestimmt.
Wenn zum Beispiel die Datengröße größer als eine spezifische Größe oder die Gültigkeitslaufzeit länger als eine spezifische Zeitspanne ist, und wenn die Art von Daten AV-Daten wie zum Beispiel Klang-, Bilddaten usw. angibt, wird beurteilt, daß kein Java-Objekt in dem Speicherbereich mit variablen Adressen 105a gespeichert wird. Wie in Ausführungsform 1 beschrieben, werden in diesem Fall Datenverwaltungsinformationen, die in dem Speicherbereich mit festen Adressen 105b gespeichert sind, durch den GOBF-Teil 102d erzeugt. Der Java-Objektbezugsteil 102b liest Daten, die in dem Speicherbereich mit festen Adressen 105b gespeichert sind, gemäß diesen Verwaltungsinformationen als Java-Objekt aus.
Wenn dagegen die Datengröße kleiner als die spezifische Größe ist oder die Datengültigkeitslaufzeit kürzer als eine spezifische Zeitspanne und wenn die Datenart von AV-Daten verschiedene gewöhnliche Daten abgibt, wird beurteilt, daß das Java-Objekt in dem Speicherbereich mit variablen Adressen 105a gespeichert wird. In diesem Fall kann das in dem Speicherbereich mit festen Adressen 105b gespeicherte Java-Objekt wie gewöhnlich in dem Speicherbereich mit variablen Adressen 105a erzeugt werden.
In der Speicherverwaltungsvorrichtung 400 gemäß Ausführungsform 3 ist der Verarbeitungsfluß vom Herunterladen der Herunterladedaten D1 bis zum Auslesen der Daten als Java-Objekt im Prinzip mit dem in Ausführungsform 1 mit Bezug auf 4 erläuterten identisch.
Aber die Speicherverwaltungsvorrichtung 400 gemäß Ausführungsform 3 ist von der Vorrichtung gemäß Ausführungsform 1 in einem Teil der Java-Objekterzeugungsverarbeitung im Schritt S5 verschieden. 9 ist ein Flußdiagramm des Flusses der Erzeugung von Java-Objekt gemäß Ausführungsform 3.
Wie in 9 gezeigt, ist der Fluß der Java-Objekterzeugung gemäß Ausführungsform 3 insofern von dem in Ausführungsform 1 verschieden, als die Schritte S40, S41 bei Ausführungsform 3 hinzugefügt sind.
Wenn im Schritt S11 eine Anforderung zur Erzeugung eines Java-Objekts erfolgt, können die Art, Größe, Gültigkeitslaufzeit usw. von in dem Speicherbereich mit festen Adressen 105b gespeicherten Herunterladedaten D1 erhalten werden.
Im Schritt S40 beurteilt auf der Grundlage der Art, Größe, Gültigkeitslaufzeit usw. der in dem Speicherbereich mit festen Adressen 105b gespeicherten Herunterladedaten D1 der Beurteilungsteil 401, ob die Herunterladedaten D1 als Java-Objekt in dem Speicherbereich mit variablen Adressen 105a gespeichert sind.
Nur wenn beurteilt wird, daß die Herunterladedaten D1 nicht als Java-Objekt in dem Speicherbereich mit variablen Adressen 105a gespeichert werden, wird der Prozeß von Schritt S12 an wie bei Ausführungsform 1 ausgeführt.
Wenn dagegen im Schritt S40 beurteilt wird, daß die Herunterladedaten D1 als Java-Objekt in dem Speicherbereich mit variablen Adressen 105a gespeichert sind, wird das Java-Objekt der Herunterladedaten D1 in dem Speicherbereich mit variablen Adressen 105a erzeugt (Schritt S41). Die Verarbeitung im Schritt S41 wird wie gewöhnlich ausgeführt, und Einzelheiten dieser Verarbeitung werden nicht erläutert.
Bei Ausführungsform 3 der vorliegenden Ausführungsform werden wie erläutert nur dann Verwaltungsinformationen erzeugt, wenn gemäß der Größe von Daten usw., die in dem Speicherbereich mit festen Adressen gespeichert sind, beurteilt wird, daß die Daten in dem Speicherbereich mit variablen Adressen gespeichert sind. Wenn die Grundlage der Beurteilung gemäß Spezifikation usw. von OS zur Verwaltung des Festadressenspeicherbereichs oder der Vorrichtung verändert wird, wird der am besten geeignete Speicherbereich zum Speichern der Daten gewählt. Dadurch wird die Speicherverwaltung effektiv durchgeführt.
Die vorliegende Erfindung wurde in den jeweiligen Ausführungsformen im einzelnen beschrieben, aber nicht auf diese Ausführungsformen beschränkt, und es versteht sich, daß Änderungen und Variationen vorgenommen werden können, ohne vom Gedanken oder Schutzumfang der Erfindung abzuweichen.
In der Speicherverwaltungsvorrichtung gemäß der vorliegenden Erfindung wird ein Java-Objekt auf der Grundlage von durch das Internet 300 heruntergeladenen Daten erzeugt. Die vorliegende Erfindung kann auch auf bewegliche Endgeräte, wie zum Beispiel Mobiltelefon, Beistellgeräte und digitales Fernsehen angewandt werden. Zum Beispiel kann bei digitalem Fernsehen die Speicherverwaltungsvorrichtung gemäß der vorliegenden Erfindung auf eine digitale Fernsehempfangsvorrichtung angewandt werden, die auf eine über das digitale Rundsendenetzwerk gesendete Trägerwelle aufgefaltete Daten empfangen kann. Wenn die vorliegende Erfindung auf digitales Fernsehen angewandt wird, wird eine Netzwerkeinrichtung (siehe 1) aus einem digitalen Rundsendeempfangstuner zum Empfangen von Daten gebildet.
Das Programm der vorliegenden Erfindung kann in der Form, in der das Programm aus dem über Kommunikationsmedien, wie zum Beispiel das Internet, verbundenen Server in den Computerspeicher oder das Plattenlaufwerk des Computers des Kunden heruntergeladen wird, vertrieben oder verkauft werden. In diesem Fall wird das Programm der vorliegenden Erfindung durch den Computer des Kunden gelesen und die Speicherverwaltungsvorrichtung bzw. das Speicherverwaltungs verfahren der vorliegenden Erfindung wird unter Verwendung dieses Computers gebildet. Weiterhin kann der folgende Modus verwendet werden. In diesem Modus können ein Programm oder Daten in einem Speicher usw. anderer Einrichtungen über Kommunikationsmedien verwendet werden.
Es kann ein weiterer Modus möglich sein, bei dem das Programm der vorliegenden Erfindung in Aufzeichnungsmedien, wie zum Beispiel CD-ROM, FD, DVD usw. gespeichert und in auswechselbarer Form Vielzweckcomputern angeboten wird. Dadurch kann das Programm der vorliegenden Erfindung leicht als Softwareprodukt abhängig von der Vorrichtung verteilt und verkauft werden. Wenn diese Software mit Hardware, wie zum Beispiel einem Vielzweckcomputer, einer Vielzweck-Spielmaschine usw. verwendet wird, kann die vorliegende Erfindung leicht mit dieser Hardware ausgeführt werden.
Gemäß der vorliegenden Erfindung werden gemäß einer Anforderung von einem objektorientierten Programm Verwaltungsinformationen erzeugt, damit ein objektorientiertes Programm von einem anderen Programm in dem Speicherbereich mit festen Adressen erzeugte Daten lesen kann. Und dadurch wird es also unnötig, heruntergeladene Daten wie im Stand der Technik auf einen durch ein Programm des objektorientierten Programms verwalteten Speicherbereich zu kopieren. Außerdem wird das Verarbeitungsoverhead entfernt, wodurch die Verarbeitungslast verringert wird und der Speicherbereich effizient verwendet werden kann.
Wenn die Ausführung der Java-Anwendung abgeschlossen ist und Daten in dem Speicherbereich mit festen Adressen nicht mehr benötigt werden, werden zusätzlich unbenötigte Daten aus dem Speicherbereich mit festen Adressen gelöscht. Und deshalb können das native Programm und freier Speicherbereich als OS- Arbeitsbereich effektiv gesichert werden.
Außerdem werden nur dann Verwaltungsinformationen erzeugt, wenn gemäß in dem Speicherbereich mit festen Adressen gespeicherten Daten beurteilt wird, daß die Daten nicht in dem Speicherbereich mit variablen Adressen gespeichert sind, wodurch die Speicherverwaltung für Daten höchst geeignet wird.

Claims

Speicherverwaltungsvorrichtung (102a) zum Verwalten eines Speichers (105) mit einem Speicherbereich mit variablen Adressen (105a), in dem ein Ausführungsobjekt gespeichert wird, das von einem virtuellen Maschinenprogramm (102a) ausgeführt wird, um ein aus einer objektorientierten Sprache gebildetes objektorientiertes Programm (101) auszuführen, wobei das Ausführungsobjekt durch das virtuelle Maschinenprogramm an eine andere Stelle gebracht wird, und einem Speicherbereich mit festen Adressen (105b), in dem Daten gespeichert werden, die von einem anderen Programm (13) erzeugt werden, das aus einer anderen Sprache als der objektorientierten Sprache gebildet wird, wobei die Vorrichtung folgendes umfaßt: ein Erzeugungsmittel zum Erzeugen von Verwaltungsinformationen für das objektorientierte Programm, die erzeugten Daten gemäß einer Anforderung durch das objektorientierte Programm zu lesen, und Lesemittel zum Lesen von Daten, die in dem Speicherbereich mit festen Adressen erzeugt werden, gemäß von dem Erzeugungsmittel erzeugten Verwaltungsinformationen, Erkennungsmittel zum Erkennen von Daten, deren Löschung gemäß einer Löschungsanforderung von dem objektorientierten Programm angefordert wird, nachdem das objektorientierte Programm ausgeführt wurde, ein Artbeurteilungsmittel zum Beurteilen, ob durch das Erkennungsmittel erkannte Daten entweder in dem Speicherbereich mit variablen Adressen oder in dem Speicherbereich mit festen Adressen gespeichert werden, ein Löschungsanforderungsspeichermittel zum Speichern einer Anforderung von dem objektorientierten Programm einer Löschung von durch das Erkennungsmittel erkannten Daten, wenn das Artbeurteilungsmittel urteilt, daß von dem Erkennungsmittel erkannte Daten in dem Speicherbereich mit festen Adressen gespeichert werden, ein Löschungsbeurteilungsmittel zum Beurteilen, ob eine Anforderung von einem anderen Programm einer Löschung von Daten, für die die Löschungsanforderung in dem Löschungsanforderungsspeichermittel gespeichert wird, vorliegt, und ein Löschungsmittel zum Löschen der erkannten Daten und Verwaltungsinformationen bezüglich der Daten, wenn das Löschungsbeurteilungsmittel urteilt, daß eine Anforderung von dem anderen Programm einer Löschung von Daten, für die die Löschungsanforderung in dem Löschungsanforderungsspeichermittel gespeichert wird, vorliegt.
Speicherverwaltungsvorrichtung nach Anspruch 1, weiterhin mit einem Kommunikationsmittel zum Empfangen von Daten in dem Speicherbereich mit festen Adressen des Speichers, wobei durch das andere Programm erzeugte Daten durch Verwendung des Kommunikationsmittels empfangen werden und das Erzeugungsmittel Verwaltungsinformationen für das objektorientierte Programm, die vom Kommunikationsmittel empfangenen Daten zu lesen, erzeugt.
Speicherverwaltungsvorrichtung nach Anspruch 2, weiterhin mit einem Datenbeurteilungsmittel zum Beurteilen gemäß in dem Speicherbereich mit festen Adressen gespeicherten Daten, ob das Ausführungsobjekt der Daten in dem Speicherbereich mit variablen Adressen gespeichert wird, und wobei das Erzeugungsmittel, wenn das Datenbeurteilungsmittel urteilt, daß das Ausführungsobjekt von in dem Speicherbereich mit festen Adressen gespeicherten Daten nicht in dem Speicherbereich mit variablen Adressen gespeichert wird, Verwaltungsinformationen bezüglich der Daten erzeugt.
Speicherverwaltungsvorrichtung nach einem der Ansprüche 1 bis 3, wobei das objektorientierte Programm aus Java gebildet wird.
Speicherverwaltungsverfahren zum Verwalten eines Speichers mit einem Speicherbereich mit variablen Adressen, in dem ein Ausführungsobjekt gespeichert wird, das von einem virtuellen Maschinenprogramm ausgeführt wird, um ein aus einer objektorientierten Sprache gebildetes objektorientiertes Programm auszuführen, wobei das Ausführungsobjekt durch das virtuelle Maschinenprogramm an eine andere Stelle gebracht wird, und einem Speicherbereich mit festen Adressen, in dem Daten gespeichert werden, die von einem anderen Programm erzeugt werden, das aus einer anderen Sprache als der objektorientierten Sprache gebildet wird, mit den folgenden Schritten: Erzeugen von Verwaltungsinformationen für das objektorientierte Programm, die erzeugten Daten gemäß einer Anforderung durch das objektorientierte Programm zu lesen, und Lesen von Daten, die in dem Speicherbereich mit festen Adressen erzeugt werden, gemäß von in dem Erzeugungsschritt erzeugten Verwaltungsinformationen, Erkennen von Daten, deren Löschung gemäß einer Löschungsanforderung von dem objektorientierten Programm angefordert wird, nachdem das objektorientierte Programm ausgeführt wurde, Beurteilen der Art, um zu beurteilen, ob in dem Erkennungsschritt erkannte Daten entweder in dem Speicherbereich mit variablen Adressen oder in dem Speicherbereich mit festen Adressen gespeichert werden, Speichern einer Anforderung von dem objektorientierten Programm einer Löschung von in dem Erkennungsschritt erkannten Daten, wenn in dem Artbeurteilungsschritt geurteilt wird, daß in dem Erkennungsschritt erkannte Daten in dem Speicherbereich mit festen Adressen gespeichert werden, Beurteilen, ob eine Anforderung von dem anderen Programm einer Löschung von Daten, für die die Löschungsanforderung in dem Löschungsanforderungsspeichermittel gespeichert wird, vorliegt, und Löschen der erkannten Daten und Verwaltungsinformationen bezüglich der Daten, wenn in dem Löschungsbeurteilungsschritt geurteilt wird, daß eine Anforderung von dem anderen Programm einer Löschung von Daten, für die die Löschungsanforderung in dem Löschungsanforderungsspeicherschritt gespeichert wird, vorliegt.
Speicherverwaltungsverfahren nach Anspruch 5, weiterhin mit einem Kommunikationsschritt des Empfangens von Daten in dem Speicherbereich mit festen Adressen des Speichers, und wobei durch das andere Programm erzeugte Daten in dem Kommunikationsschritt empfangene Daten sind und der Erzeugungsschritt Verwaltungsinformationen für das objektorientierte Programm erzeugt, durch den Kommunikationsschritt empfangene Daten zu lesen.
Speicherverwaltungsverfahren nach Anspruch 5, weiterhin mit einem Datenbeurteilungsschritt des Urteilens gemäß in dem Speicherbereich mit festen Adressen gespeicherten Daten, ob das Ausführungsobjekt der Daten in dem Speicherbereich mit variablen Adressen gespeichert wird, und wobei in dem Erzeugungsschritt, wenn in dem Datenbeurteilungsschritt geurteilt wird, daß das Ausführungsobjekt von in dem Speicherbereich mit festen Adressen gespeicherten Daten nicht in dem Speicherbereich mit variablen Adressen gespeichert wird, Verwaltungsinformationen bezüglich der Daten erzeugt werden.
Speicherverwaltungsvorrichtung nach einem der Ansprüche 5 bis 7, wobei das objektorientierte Programm aus Java gebildet wird.
Speicherverwaltungsprogramm zum Verwalten eines Speichers mit einem Speicherbereich mit variablen Adressen, in dem ein Ausführungsobjekt gespeichert wird, das von einem virtuellen Maschinenprogramm ausgeführt wird, um ein aus einer objektorientierten Sprache gebildetes objektorientiertes Programm auszuführen, wobei das Ausführungsobjekt durch das virtuelle Maschinenprogramm an eine andere Stelle gebracht wird, und einem Speicherbereich mit festen Adressen, in dem Daten gespeichert werden, die von einem anderen Programm erzeugt werden, das aus einer anderen Sprache als der objektorientierten Sprache gebildet wird, und das einen Computer ein Speicherverwaltungsverfahren ausführen läßt, das die Schritte beliebiger der Ansprüche 5 bis 8 enthält.
Computerlesbares Speichermedium, das ein Speicherverwaltungsprogramm zum Verwalten eines Speichers mit einem Speicherbereich mit variablen Adressen, in dem ein Ausführungsobjekt gespeichert wird, das von einem virtuellen Maschinenprogramm ausgeführt wird, um ein aus einer objektorientierten Sprache gebildetes objektorientiertes Programm auszuführen, wobei das Ausführungsobjekt durch das virtuelle Maschinenprogramm an eine andere Stelle gebracht wird, und einem Speicherbereich mit festen Adressen mit Daten, die von einem anderen Programm erzeugt werden, das aus einer anderen Sprache als der objektorientierten Sprache gebildet wird, und das einen Computer ein Speicherverwaltungsverfahren ausführen läßt, das die Schritte beliebiger der Ansprüche 5 bis 8 enthält, speichert.