-
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.