-
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 Verarbeitungsfluss
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 Verarbeitungsfluss, 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 Beispiele
können
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.
-
Aus
dem Beitrag von KENNETH B RUSSELL: „Re: Inter process communication" INTERNET, 6.11.1998
(1998-11-06) XP002192816, abgerufen aus dem Internet:
URL:HTTP://OSS.SGI.COM/PROJECTS/PERFORMER/MAIL/INFO- PERFORMER/PERF-98-11/0042.HTML> [abgerufen am 12.03.2002],
dass eine Kommunikation verschiedener Programme, einschließlich objektorientierter
Programme, unter Verwendung von gemeinsam benutztem Speicher hergestellt
werden kann.
-
Ein
Problem entsteht, wenn eines der beiden Programme seine Objekte
einer Müllsammlung
unterzieht, da die nachfolgende Verlagerung einem sich Müllsammlung
der nicht bewussten nativen Programm mitgeteilt werden müsste.
-
Dies
könnte
gelöst
werden, indem man die Daten aus dem gemeinsam benutzten Festadressenspeicherbereich
stimmig in den müllgesammelten Speicherbereich
mit variablen Adressen kopiert.
-
Beim
Kopieren großer
und langlebiger Objekte in dem Speicherbereich mit variablen Adressen entsteht
jedoch das Problem, dass die in den Speicherbereich mit variablen
Adressen kopierten Daten danach als Folge des Wirkens des Müllsammlers
einer weiteren Verlagerung unterzogen würden, was im Fall großer Objekte
zeitaufwendig und darüber
hinaus für
langlebige Objekte häufig
sein würde, obwohl
es für
kleine und kurzlebige Daten kein signifikantes Overhead darstellen
würde,
da das Müllsammel-Overhead insignifikant
wäre und
nur selten auftreten würde.
-
Die
vorliegende Erfindung löst
dieses Problem durch Bereitstellung von Beurteilungsmitteln und
Schritten, die abhängig
von der Größe oder
der Gültigkeitslaufzeit
heruntergeladener Daten entscheiden, ob heruntergeladene Daten in
dem Festadressenspeicherbereich lediglich in dem Speicherbereich
mit variablen Adressen referenziert oder darin kopiert werden sollen.
-
Folglich
ist eine Aufgabe der vorliegenden Erfindung die Durchführung der
Speicherverwaltung dergestalt, dass Overhead bei der Verlagerung
vermieden und der Speicherbereich effizienter ausgenutzt wird. Die
Aufgabe wird durch die Vorrichtung von Anspruch 1 und das Verfahren
von Anspruch 8 gelöst.
-
Eine
Aufgabe der vorliegenden Erfindung ist folglich die Durchführung der
Speicherverwaltung dergestalt, dass Overhead bei Umordnung vermieden
wird und eine effizientere Verwendung des Speicherbereichs erfolgt.
-
Außerdem kann
das Speicherverwaltungsverfahren einen Detektionsschritt, einen
Artenbeurteilungsschritt, einen Löschungsanforderungsspeicherschritt,
einen Löschungsbeurteilungsschritt
und einen Löschschritt
umfassen. Als erstes werden im Detektionsschritt Daten, deren Löschung gemäß einer
Anforderung der Löschung
aus dem objektorientierten Programm angefordert wird, vorzugsweise nach
der Ausführung
des objektorientierten Programms detektiert. In dem Klassenbeurteilungsschritt
wird vorzugsweise beurteilt, ob die im Detektionsschritt detektierten
Daten entweder in dem Speicherbereich mit variablen Adressen oder
in dem Festadressenspeicherbereich gespeichert sind. In dem Löschungsanforderungsspeicherschritt
wird, wenn in dem Artenbeurteilungsschritt beurteilt wird, dass
die in dem Detektionsschritt detektierten Daten vorzugsweise in
dem Festadressenspeicherbereich gespeichert werden, eine Anforderung
von dem objektorientierten Programm zur Löschung der in dem Detektionsschritt
detektierten Daten vorzugsweise gespeichert. In dem Löschungsanforderungsschritt wird
ferner vorzugsweise beurteilt, ob eine Anforderung von einem anderen
Programm der Löschung von
Daten, für
die die Löschungsanforderung
in dem Löschungsanforderungsspeicherschritt
gespeichert wurde, vorliegt. Und in dem Löschschritt werden, wenn beurteilt
wird, dass eine Anforderung von einem anderen Programm der Löschung von
Daten, für die
die Löschungsanforderung
in dem Löschungsanforderungsschritt
gespeichert wurde, vorliegt, die detektierten Daten und die Verwaltungsinformationen vorzugsweise
gelöscht.
-
Ferner
kann das Speicherverwaltungsprogramm einen Datenbeurteilungsschritt
umfassen, der beurteilt, ob das Ausführungsobjekt von Daten gemäß in dem
Festadressenspeicherbereich gespeicherten Daten in dem Speicherbereich
mit variablen Adressen gespeichert ist. In dem Erzeugungsschritt werden,
wenn durch das Datenbeurteilungsmittel beurteilt wird, dass das
Ausführungsobjekt
in dem Festadressenspeicherbereich gespeicherten Daten nicht in
dem Speicherbereich mit variablen Adressen gespeichert ist, vorzugsweise
Verwaltungsinformationen bezüglich
der Daten erzeugt.
-
Außerdem kann
die vorliegende Erfindung als Speicherverwaltungsprogramm oder als
das Speicherverwaltungsprogramm speicherndes computerlesbares Speichermedium
ausgeführt
werden.
-
Dieses
Speicherverwaltungsprogramm ist ein Programm, wodurch der Computer
das oben erwähnte
Speicherverwaltungsverfahren ausführt. Bei dem durch Computer
gelesenen Speicherverwaltungsprogramm kooperieren Software- und
Hardwarebetriebsmittel, um das Erzeugen von Verwaltungsinformationen
bezüglich
der in dem Festadressenspeicherbereich gespeicherten Daten und das Lesen
von Daten auf der Basis der Verwaltungsinformationen zu materialisieren.
Folglich wird eine Speicherverwaltungsvorrichtung zum Beispiel durch
Verwendung eines Computers aufgebaut. Wenn ein Computer, in dem
ein Speicherverwaltungsprogramm gelesen wird, arbeitet, wird außerdem ein Speicherverwaltungsverfahren
aufgebaut.
-
Speicherverwaltungsprogramme
können über Kommunikationsmedien
wie zum Beispiel das Internet vertrieben oder verkauft werden und
können außerdem in
einer in einem Speichermedium gespeicherten Form vertrieben oder
verkauft werden.
-
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 Prozessflusses vom Empfangen heruntergeladener Daten
bis zum Auslesen heruntergeladener Daten als Java-Objekt gemäß Ausführungsform
1;
-
5 ein
Flussdiagramm des Flusses der Java-Objekterzeugung gemäß Ausführungsform
1;
-
6 ein
Funktionsblockschaltbild einer groben Konfiguration einer Speicherverwaltungsvorrichtung
gemäß Ausführungsform
2;
-
7 ein
Flussdiagramm 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
Flussdiagramm 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 104 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, dass 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 Beispiele 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, dass 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
Flussdiagramm 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 Prozess 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 103 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 Speicherverwaltungsvorrichtung
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, dass 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 muss nicht gesagt werden, dass 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,
Festadressenspeicherbereitstellungsteil 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.
-
Die
Speicherverwaltungsvorrichtung 200 umfasst weiterhin einen
Müllverarbeitungsteil 202a.
-
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 105a 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 105a gespeichert
sind.
-
Der
Löschungsbeurteilungsteil 206 für Speicher
mit festen Adressen beurteilt, ob der Java-Objektartbeurteilungsteil 204 urteilt,
dass 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 Verarbeitungsfluss des Löschens unbenötigter Java-Objekte
in dem Objektspeicherteil 105 erläutert. 7 ist ein
Flussdiagramm 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 S22).
-
Als
nächstes
erkennt der Bezugswiderrufsobjektdetektionsteil 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, dass 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, dass 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, dass 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
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, dass 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,
dass 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, dass 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 Verarbeitungsfluss 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
Flussdiagramm des Flusses der Erzeugung von Java-Objekt gemäß Ausführungsform
3.
-
Wie
in 9 gezeigt, ist der Fluss 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 Größe oder Gültigkeitslaufzeit 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, dass die Herunterladedaten D1 nicht als Java-Objekt in dem Speicherbereich
mit variablen Adressen 105a gespeichert werden, wird der
Prozess von Schritt S12 an wie bei Ausführungsform 1 ausgeführt.
-
Wenn
dagegen im Schritt S40 beurteilt wird, dass 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, dass 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, dass Ä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 Speicherverwaltungsverfahren
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, dass die Daten nicht in dem Speicherbereich mit variablen
Adressen gespeichert sind, wodurch die Speicherverwaltung für Daten
höchst
geeignet wird.