DE69834087T2

DE69834087T2 - Verfahren und Gerät zur Vorverarbeitung und Verpackung von Klassendateien

Info

Publication number: DE69834087T2
Application number: DE69834087T
Authority: DE
Inventors: Nedim San Francisco FRESKO; Richard San Francisco Tuck
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1997-10-31
Filing date: 1998-10-28
Publication date: 2006-11-23
Anticipated expiration: 2018-10-29
Also published as: KR100562398B1; EP0913769B1; US6530080B2; US5966702A; EP0913769A2; KR19990037560A; DE69834087D1; EP0913769A3; US20030009743A1; JP2000029706A

Description

HINTERGRUND DER ERFINDUNG
ERFINDUNGSGEBIET
Diese Erfindung betrifft das Gebiet der Computersoftware, und genauer, objektorientierte Computeranwendungen.
STAND DER TECHNIK
Infolge der Fortschritte in der Netzwerktechnologie hat der Einsatz von Netzwerken zur Erleichterung der Verteilung von Medieninformationen, wie beispielsweise Text, Graphik und Audio, drastisch zugenommen, insbesondere hinsichtlich Internet und World Wide Web. Ein Schwerpunktgebiet derzeitiger Forschungsbemühungen ist das Gebiet der Webanwendungen und der Netzwerkinteraktivität. Neben passiven Medieninhalten, wie HTML-Definitionen, sind an das Netzwerk gekoppelte Computernutzer oder „Clients" in der Lage, auf Anwendungsinhalte zuzugreifen oder sie herunterzuladen, in der Form von Applets, beispielsweise von „Servern" im Netzwerk.
Um der Vielfalt der von Clients genutzten Hardwaresystemen gerecht zu werden, werden die Anwendungen oder Applets in einem plattformunabhängigen Format, beispielsweise dem Java^®-Class-Datei-Format, verteilt. Objektorientierte Anwendungen werden aus mehreren Class-Dateien gebildet, auf die von Servern zugegriffen wird und die einzeln nach Bedarf heruntergeladen werden. Class-Dateien enthalten Bytecode-Anweisungen. Ein „Virtual-Machine"-Prozess, der auf einer bestimmten Hardwareplattform ausgeführt wird, lädt die einzelnen Class-Dateien und führt die enthaltenen Bytecodes aus.
Ein mit dem Class-Datei-Format und dem Class-Lade-Prozeß verbundenes Problem ist, daß die Class-Dateien oft doppelte Daten enthalten. Die Speicherung, der Transfer und die Verarbeitung der einzelnen Class-Dateien ist somit aufgrund der Redundanz der Informationen ineffizient. Eine Anwendung kann außerdem viele Class-Dateien enthalten, die alle in separaten Transaktionen geladen und verarbeitet werden. Dies verlangsamt die Anwendung und verschlechtert die Leistung des Speicherzuweisers. Darüber hinaus muss ein Client für die Dauer der Anwendung eine physische Verbindung zu dem Server aufrechterhalten, um auf die abrufbaren Class-Dateien zuzugreifen.
Eine Übersicht allgemeinen objektorientierten Programmierens und ein Beispiel einer derzeitigen Netzwerkanwendungsumgebung verdeutlicht diese Schwierigkeiten.
Objektorientiertes Programmieren
Objektorientiertes Programmieren ist ein Verfahren zum Erstellen von Computerprogrammen durch Kombinieren bestimmter Basisbausteine und Erzeugen von Beziehungen zwischen den Bausteinen. In objektorientierten Programmierungssystemen werden die Bausteine „Objekte" genannt. Ein Objekt ist eine Programmiereinheit, die eine Datenstruktur (eine oder mehrere Instanzvariablen) und die Operationen (Methoden), die diese Daten verwenden oder beeinflussen können, zusammengruppiert. Ein Objekt besteht somit aus Daten und einer oder mehreren Operationen oder Abläufen, die an diesen Daten ausgeführt werden können. Die Verbindung von Daten und Operationen in einem einheitlichen Baustein wird „Verkapselung" genannt.
Ein Objekt kann angewiesen werden, eine seiner Methoden auszuführen, wenn es eine „Nachricht" erhält. Eine Nachricht ist ein Befehl oder eine Anweisung, der bzw. die an das Objekt gesendet wird, damit dieses eine bestimmte Methode ausführt. Eine Nachricht besteht aus einer Methodenauswahl (z.B. Methodenname) und mehreren Argumenten. Eine Nachricht sagt dem empfangenden Objekt, welche Operation es ausführen soll.
Ein Vorteil objektorientierten Programmierens ist die Weise, in der Methoden aufgerufen werden. Wird eine Nachricht an ein Objekt gesendet, so ist es nicht nötig, daß die Nachricht das Objekt darüber instruiert, wie eine bestimmte Methode ausgeführt werden soll. Es ist lediglich notwendig, anzufordern, daß das Objekt die Methode ausführt. Dies vereinfacht die Programmentwicklung erheblich.
Objektorientierte Programmiersprachen basieren vorwiegend auf einem „Class"-Schema. Das klassenbasierte objektorientierte Programmierungsschema wird allgemein in Liebermann, „Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems", OOPSLA 86 Proceedings, September 1986, S. 214–223 beschrieben.
Eine Klasse definiert eine Objektart, die in der Regel sowohl Variablen als auch Methoden für die Klasse enthält. Eine Objektklasse wird zum Erzeugen einer bestimmten Objektinstanz verwendet. Eine Instanz einer Objektklasse enthält die für die Klasse definierten Variablen und Methoden. Aus einer Objektklasse können mehrere Instanzen derselben Klasse erzeugt werden. Jede aus der Objektklasse erzeugte Instanz gilt als derselben Art oder Klasse zugehörig.
Zur Verdeutlichung kann eine Angestellten-Objektklasse die Instanzvariablen „Name" und „Gehalt" und eine Methode „setze_Gehalt" enthalten. Für jeden Angestellten in einem Unternehmen können Instanzen der Angestellten-Objektklasse erzeugt oder initiiert werden. Jede Angstellten-Objektinstanz gilt als der Art „Angestellter" zugehörig. Jede Angestellten-Objektinstanz enthält die Instanzvariablen „Name" und „Gehalt" und die Methode „setze_Gehalt". Die Werte, die in jeder Angestellten-Objektinstanz den Variablen „Name" und „Gehalt" zugeordnet sind, enthalten den Namen und das Gehalt eines Angestellten in dem Unternehmen. An die Angestellten-Objektklasse eines Angestellten kann eine Nachricht gesendet werden, um die Methode „setze_Gehalt" aufzurufen, um das Gehalt des Angestellten zu modifizieren (d.h. der in dem Angstellten-Objekt eines Angestellten der Variablen „Gehalt" zugeordnete Wert).
Eine Klassenhierarchie kann so definiert werden, daß eine Objektklassendefinition eine oder mehrere Unterklassen hat. Eine Unterklasse erbt die Definition seiner Elternklasse (und Großelternklasse usw.). Jede Unterklasse kann das durch seine Elternklasse angegebene Verhalten ergänzen oder modifizieren. Von einigen objektorientierten Programmiersprachen wird eine Mehrfachbeerbung unterstützt, bei der eine Unterklasse eine Klassendefinition von mehr als einer Elternklasse erben kann. Andere Programmiersprachen unterstützen lediglich eine einfache Beerbung, bei der eine Unterklasse darauf beschränkt ist, die Klassendefinition von nur einer Elternklasse zu erben. Die Java-Programmiersprache stellt auch einen als „Schnittstelle" bekannten Mechanismus bereit, der eine Gruppe konstanter und abstrakter Methodenerklärungen enthält. Eine Objektklasse kann die in einer Schnittstelle definierten Methoden umsetzen. Für eine Schnittstelle sind sowohl Einfach- als auch Mehrfachbeerbung möglich. Das heißt, eine Schnittstelle kann eine Schnittstellendefinition von mehr als einer Elternschnittstelle erben.
Ein Objekt ist ein generischer Begriff, der in der objektorientierten Programmierungsumgebung mit Bezug auf ein Modul verwendet wird, das einen verwandten Code und Variablen enthält. Eine Softwareanwendung kann mittels einer objektorientierten Programmierungssprache geschrieben werden, wodurch die Funktionalität des Programms mit Hilfe von Objekten umgesetzt wird.
Ein Java-Programm besteht aus einer Reihe von Klassen und Schnittstellen. Anders als viele Programmiersprachen, in denen ein Programm in maschinenabhängige, ausführbare Programmcodes kompiliert wird, werden Javaklassen in maschinenunabhängige Bytecode-Class-Dateien kompiliert. Jede Klasse enthält den Code und die Daten in einem plattformunabhängigen Format, das Class-Datei-Format genannt wird. Das als Ausführungsvehikel verwendete Computerprogramm enthält ein Virtual-Machine genanntes Programm, das für die Ausführung des Codes in Javaklassen verantwortlich ist. Die Virtual-Machine stellt einen Abstraktionsgrad zwischen der Maschinenunabhängigkeit der Bytecode-Klassen und der maschinenabhängigen Anweisungsgruppe des zugrundeliegenden Hardware-Systems. Ein „Class-Loader" in der Virtual-Machine ist für das Laden der Bytecode-Class-Dateien nach Bedarf verantwortlich, und entweder führt ein Übersetzer die Bytecodes direkt aus oder ein „Just-in-time"(JIT)-Kompilierer wandelt die Bytecodes in Maschinencode um, so daß sie von dem Prozessor ausgeführt werden können. 1 ist ein Blockdiagramm, das eine beispielhafte Java-Netzwerk-Umgebung mit einer Client-Plattform 102 zeigt, die über ein Netzwerk 101 mit einem Server 100 gekoppelt ist, um zur Durchführung einer Java-Anwendung oder eines Java-Applets auf Java-Class-Dateien zuzugreifen.
Beispielhafte Java-Netzwerk-Anwendungs-Umgebung
Der Server 100 umfaßt in 1 eine Java-Entwicklungsumgebung 104 zur Verwendung bei der Erzeugung von Java-Class-Dateien für eine bestimmte Anwendung. Die Java-Entwicklungsumgebung 104 stellt einen Mechanismus, beispielsweise einen Editor oder einen Applet-Anzeiger bereit, um Class-Dateien zu erzeugen und eine Vorschau der Applets zu bieten. Eine Gruppe Java-Kern-Klassen 103 umfaßt eine Bibliothek von Javaklassen, auf die von Quelldateien verwiesen werden kann, die andere/neue Javaklassen enthalten. Von der Java-Entwicklungs-Umgebung 104 werden eine oder mehrere Java-Quelldateien 105 generiert. Die Java-Quelldateien 105 enthalten die für den Programmierer lesbaren Klassendefinitionen, einschließlich Datenstruktur, Methodenumsetzungen und Bezüge zu anderen Klassen. Die Java-Quelldateien 105 werden einem Java-Kompilierer 106 bereitgestellt, der Java-Quelldateien 105 in kompilierte „Class"-Dateien 107 kompiliert, welche Bytecodes enthalten, die von einer Java-Virtual-Machine ausführbar sind. Bytecodes-Class-Dateien 107 werden auf dem Server 100 gespeichert (d.h. in den Zwischenspeicher oder den permanenten Speicher) und stehen zum Herunterladen über das Netzwerk 101 zur Verfügung.
Die Client-Plattform 102 enthält eine Java-Virtual-Machine (JVM) 111, die aufgrund der Verwendung verfügbarer Signale 112 eines nativen Betriebssystems (O/S) zur Ausführung von Bytecode-Class-Dateien und nativer (O/S)-Signale in der Lage ist, falls dies während der Ausführung erforderlich ist.
Java-Class-Dateien werden in einem HTML-Dokument (Hypertext Markup Language) oft mittels Applet-Tags identifiziert. Eine Web-Server-Anwendung 108 wird auf dem Server 100 so ausgeführt, daß sie auf HTTP-(Hypertext Transport Protocol)-Anforderungen, die URLs (Universal Resource Locators) für HTML-Dokumente (auch „Webseiten" genannt) enthalten, reagiert. Wenn eine auf einer Client-Plattform 102 ausgeführte Browser-Anwendung ein HTML-Dokument anfordert, wie beispielsweise durch Weiterleiten von URL 109 an den Webserver 108, initiiert der Browser automatisch das Herunterladen der Class-Dateien 107, die in dem Applet-Tag des HTML-Dokuments identifiziert sind. Die Class-Dateien 107 werden in der Regel vom Server heruntergeladen und einzeln nach Bedarf in die Virtual-Machine 111 geladen.
Für die Klassen eines Java-Programms ist es üblich, daß sie nach Möglichkeit erst bei der Ausführung des Programms geladen werden; sie werden nach Bedarf von dem Netzwerk (auf einem Server gespeichert) oder von einem lokalen Dateisystem geladen, wenn auf sie erstmals während der Ausführung des Java-Programms Bezug genommen wird. Die Virtual-Machine lokalisiert und lädt jede Class-Datei, analysiert das Class-Datei-Format, weist den verschiedenen Komponenten der Klasse Speicherplatz zu und verbindet die Klasse mit anderen bereits geladenen Klassen. Dieser Prozeß führt dazu, daß der Code der Klasse durch die Virtual-Machine leicht ausgeführt werden kann.
Der individualisierte Class-Lade-Prozeß hat, so wie er üblicherweise ausgeführt wird, einige Nachteile hinsichtlich der Verwendung von Speicherressourcen auf Speichervorrichtungen, der Zuweisung von Speicherplatz und der Ausführungsgeschwindigkeit und -kontinuität. Diese Nachteile werden dadurch erschwert, daß eine typische Java-Anwendung Hunderte oder Tausende kleiner Class-Dateien enthalten kann. Jede Klasse ist eigenständig. Dies führt oft zu Informationsredundanzen zwischen Class-Dateien, beispielsweise, wenn zwei oder mehrere Class-Dateien gemeinsame Konstanten teilen. Daher brauchen viele Klassen große Speicherbereiche auf permanenten Speichervorrichtungen auf ineffiziente Art und Weise, um doppelt vorliegende Informationen einzeln zu speichern. Analog führt auch das einzelne Laden jeder Class-Datei zu unnötiger Verdopplung von Informationen in Anwendungsspeichern. Darüber hinaus wird der AuflösungsProzeß für die Konstanten unnötig wiederholt, weil gemeinsame Konstanten für jede Klasse während der Ausführung des Java-Codes getrennt aufgelöst werden.
Weil die Klassen jede für sich geladen wird, benötigt jede kleine Klasse eine eigene Gruppe von Zuweisungen von dynamischem Speicherplatz. Dies führt zur Fragmentation des Speichers und somit zur Verschwendung von Speicherplatz und verschlechtert die Leistung des Zuweisers. Für jede Klasse wird außerdem eine einzelne Lade-„Transaktion" benötigt. Die Virtual-Machine sucht nach einer Class-Datei entweder auf einer Netzwerkvorrichtung oder in einem lokalen Dateisystem und stellt eine Verbindung her, um die Klasse zu laden und zu analysieren. Dies ist ein verhältnismäßig langsamer Prozeß, der für jede Klasse wiederholt werden muss. Die Ausführung eines Java-Programms neigt bei der Reaktion/Ausführung zu unbestimmten Pausen, die durch jede Ladeprozedur einer Klasse verursacht werden, insbesondere, wenn die Klassen über ein Netzwerk geladen werden. Diese Pausen sind für Systeme, für die die interaktive oder Echtzeit-Ausführung wichtig ist, problematisch.
Ein weiterer Nachteil des Ladeprozesses einzelner Klassen ist, daß der Computer, der das Java-Programm ausführt, mit der Quelle der Java-Dateien für die Ausführungsdauer des Programms physisch verbunden bleiben muss. Dies ist insbesondere für mobile oder eingebettete Computer ohne lokale Speicherplatten oder eigenen Netzwerkzugriff problematisch. Wird die physische Verbindung während der Ausführung des Java-Programms unterbrochen, dann kann auf die Class-Dateien nicht zugegriffen werden und die Anwendung scheitert, sobald eine neue Klasse benötigt wird. Es passiert außerdem oft, daß die physische Verbindung zu Netzwerken wie dem Internet Kosten mit sich bringt, die mit der Dauer der Verbindung verknüpft sind. Zu der Unbequemlichkeit, eine Verbindung während der Ausführungsdauer einer Anwendung aufrechtzuerhalten, kommen für den Nutzer auch noch Kosten, die sich aus der physischen Verbindung ergeben.
Zur Gruppierung von Class-Dateien in ein einzelnes transportierbares Paket, das JAR-Datei genannt wird, wurde ein Java-Archiv-(JAR)-Format entwickelt. Eine JAR-Datei kann in einem HTML-Dokument in einem Applet-Tag identifiziert werden. Wenn eine Browser-Anwendung das HTML-Dokument liest und das Applet-Tag findet, wird die JAR-Datei auf den Client-Computer heruntergeladen und dekomprimiert. Eine Gruppe von Class-Dateien kann somit in einer einzigen Lade-Transaktion von einem Server zu einem Client heruntergeladen werden. Nach dem Herunterladen und Dekomprimieren sind die archivierten Class-Dateien auf dem Clientsystem für das individuelle Laden nach Bedarf gemäß Standard-Klassen-Lade-Verfahren verfügbar. Die archivierten Class-Dateien unterliegen weiterhin Speicherineffizienzen aufgrund von Datenverdopplung zwischen den Dateien sowie Speicherfragmentierung aufgrund der Durchführung einzelner Speicherplatzzuweisungen für jede Class-Datei.
Aus EP 0 702 291 A1 ist ein Verfahren und ein Mechanismus zum Aufrufen von Objekten mit Schnittstellenbeerbung bekannt. Ein Objektbezug verwendet zweiteilige m-Tabellen; insbesondere wird ein Zeiger auf Daten für ein Objekt und ein Zeiger auf Methoden auf dem Objekt beschrieben. Die Methoden auf dem Objekt werden durch eine Sammlung von m-Tabellen dargestellt. Eine m-Tabelle für eine bestimmte Schnittstelle besteht aus Zeigern auf m-Tabellen für geerbte Schnittstellen und Zeiger auf Funktionen, die die in der Schnittstelle erklärten Operationen umsetzen.
Aus dem Artikel „Object-oriented Programming in C The Linnaeus System" IBM Technical Disclosability, Bd.32, Nr.9B, S. 437–439 ist das Linnaeus-System bekannt, das objektorientiertes Programmieren in der C-Programmier-Sprache bereitstellt. Das Linnaeus-System ermöglicht objektorientiertes Programmieren in einer nicht-OOP-Sprache. Der Ansatz vereint die Vorteile von objektorientiertem Programmieren mit der Effizienz der Verwendung einer kompilierten Sprache. Wird ein Objekt instanziert, so trägt es einen Zeiger auf die entsprechende Klassentabelle. Objekte tragen keine ausdrücklichen Zeiger auf Methoden und es gibt nur eine Kopie jeder Klassentabelle.
KURZE DARSTELLUNG DER ERFINDUNG
Es wird ein Verfahren und eine Vorrichtung zum Vorverarbeiten und Paketieren von Class-Dateien beschrieben. Ausführungsformen der Erfindung entfernen doppelte Informationselemente aus einer Gruppe von Class-Dateien, um die Größe der einzelnen Class-Datei zu reduzieren und eine redundante Auflösung der Informationselemente zu verhindern. Speicherzuweisungserfordernisse werden im Voraus für die Gruppe der Klassen als Ganzes bestimmt, um die Komplexizität der Speicherzuweisung zu verringern, wenn die Gruppe von Klassen geladen wird. Für die effiziente Speicherung, den Transfer und Verarbeitung als eine Einheit werden die Class-Dateien in einem einzelnen Paket gespeichert.
In einer Ausführungsform der Erfindung untersucht ein Vor-Prozessor jede Class-Datei in einer Gruppe von Class-Dateien, um doppelte Informationen in Form von redundanten Konstanten in einem Konstanten-Pool zu lokalisieren. Die doppelte Konstante wird in eine getrennte gemeinsame Tabelle platziert und alle Vorkommnisse der Konstante werden aus der jeweiligen Konstanten-Pool der individuellen Class-Dateien entfernt. Während der Vorverarbeitung werden für jede Class-Datei Speicherzuweisungserfordernisse bestimmt und werden für die Bestimmung eines Gesamtspeicherzuweisungserfordernis für die Gruppe von Class-Dateien verwendet. Die gemeinsame Tabelle, das Speicherzuweisungserfordernis und die reduzierten Class-Dateien werden als eine Einheit in eine Multi-Class-Datei gepackt.
Wünscht eine Virtual-Machine das Laden der Klassen in der Multi-Class-Datei, so wird der Ort der Mehrfach-Class-Datei bestimmt und die Multi-Class-Datei wird bei Bedarf von einem Server heruntergeladen. Die Speicherzuweisungsinformation in der Multi-Class-Datei wird von der Virtual-Machine dazu verwendet, Speicher aus dem Heap der Virtual-Machine für der Gruppe von Klassen zuzuweisen. Die einzelnen Klassen werden mit entsprechenden reduzierten Konstanten-Pools zusammen mit den gemeinsam genutzten Tabellen in die Virtual-Machine geladen. An den reduzierten Konstanten-Pools und den gemeinsam genutzten Dateien wird nach Bedarf eine Konstanten-Auflösung durchgeführt.
KURZE BESCHREIBUNG DER FIGUREN
1 ist eine Ausführungsform einer Java-Netzwerk-Anwendungs-Umgebung.
2 ist ein Blockdiagram einer Ausführungsform eines Computersystems, das zum Bereitstellen einer geeigneten Ausführungsumgebung für eine Ausführungsform der Erfindung in der Lage ist.
3 ist ein Blockdiagramm einer Ausführungsform eines Class-Datei-Formats.
4 ist ein Flussdiagramm eines Class-Datei-Vorverarbeitungs-Verfahrens gemäß einer Ausführungsform der Erfindung.
5 ist ein Blockdiagramm eines Mehrfach-Class-Datei-Formats gemäß einer Ausführungsform der Erfindung.
6 ist ein Blockdiagramm von Runtime-Daten-Gebieten einer Virtual-Machine gemäß einer Ausführungform der Erfindung.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Die Erfindung ist ein Verfahren und eine Vorrichtung zum Vorverarbeiten und Paketieren von Class-Dateien. In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um eine gründlichere Beschreibung von Ausführungsformen der Erfindung bereitzustellen. Einem Fachmann dürfte jedoch klar sein, daß die Erfindung auch ohne diese spezifischen Einzelheiten ausgeführt werden kann. An anderen Stellen wurden wohlbekannte Merkmale nicht näher beschrieben, um die Erfindung nicht undeutlicher zu machen.
AUSFÜHRUNGSFORM DER COMPUTERAUSFÜHRUNGSUMGEBUNG (Hardware)
Eine Ausführungsform der Erfindung kann als Computer-Software in Form eines computerlesbaren Programmcodes umgesetzt werden, der auf einem Allzweck-Computer, wie dem in 2 gezeigten Computer 200 ausgeführt wird, oder in Form von Bytecode-Class-Dateien, die durch eine auf einem solchen Computer laufende Virtual-Machine ausführbar sind. Eine Tastatur 210 und eine Maus 211 sind an einen bidirektionalen Systembus 218 gekoppelt. Die Tastatur und die Maus dienen der Einführung von Benutzereingaben in das Computersystem und dem Übermitteln dieser Benutzereingaben an eine Zentrale Verarbeitungseinheit (CPU) 213. Andere geeignete Eingabevorrichtungen können zusätzlich zu oder anstelle von der Maus 211 und der Tastatur 210 verwendet werden. Eine E/A-(Eingabe/Ausgabe)-Einheit 219, die an einen bidirektionalen Systembus 218 gekoppelt ist, steht für solche E/A-Elemente, wie beispielsweise einen Drucker, A/V-(Audio/Video)-E/A usw.
Der Computer 200 enthält einen Videospeicher 214, einen Hauptspeicher 215 und einen Massenspeicher 212, die zusammen mit der Tastatur 210, der Maus 211 und der CPU 213 alle an einen bidirektionalen Systembus 218 gekoppelt sind. Der Massenspeicher 212 kann sowohl feste als auch entfernbare Medien, wie beispielsweise magnetische, optische oder magnetooptische Speichersysteme, oder beliebige andere erhältliche Massenspeichertechnologie enthalten. Der Bus 218 kann beispielsweise 32 Adresszeilen zum Adressieren des Videospeichers 214 oder des Hauptspeichers 215 enthalten. Der Systembus 218 enthält außerdem beispielsweise, einen 32-Bit-Datenbus für die Datenübertragung zwischen und unter den Komponenten, wie CPU 213, Hauptspeicher 215, Videospeicher 214 und Massenspeicher 212. Alternativ können Multiplexdaten-/Adresszeilen anstelle getrennter Daten- und Adresszeilen verwendet werden.
In einer Ausführungsform der Erfindung handelt es sich bei der CPU 213 um einen von Motorola^® hergestellten Mikroprozessor, beispielsweise den 680X0-Prozessor, oder einen von Intel^® hergestellten Mikroprozessor, beispielsweise den 80X86, oder einen Pentium^®-Prozessor, oder einen SPARC^®-Mikroprozessor von Sun Microsystems^®. Jeder andere geeignete Mikroprozessor oder Mikrocomputer kann jedoch verwendet werden. Der Hauptspeicher 215 besteht aus einen Dynamischen Direktzugriffsspeicher (DRAM). Der Videospeicher 214 ist ein zweiportiger Video-Direktzugriffsspeicher. Ein Port des Videospeichers 214 ist mit einem Videoverstärker 216 verbunden. Der Videoverstärker 216 wird verwendet, um den Katodenstrahlröhren(CRT)-Raster-Monitor 217 anzutreiben. Der Videoverstäker wird dazu verwendet, den Kathodenstrahlröhren-(CRT)-Raster-Monitor 217 anzusteuern. Der Videoverstärker ist wohlbekannt und kann durch jede geeignete Vorrichtung umgesetzt werden. Diese Schaltung wandelt in dem Videospeicher 216 gespeicherte Pixeldaten in ein Rastersignal um, das sich für die Verwendung durch den Monitor 217 eignet. Der Monitor 217 ist eine Art Monitor, die sich zum Anzeigen graphischer Bilder eignet.
Der Computer 200 kann auch eine mit dem Bus 218 gekoppelte Kommunikationsschnittstelle 220 enthalten. Die Kommunikationsschnittstelle 220 stellt eine Zwei-Wege-Datenkommunikationskopplung über die Netzwerkverbindung 221 zu einem lokalen Netzwerk 222 bereit. Zum Beispiel stellt die Kommunikationsschnittstelle 220, wenn es sich um eine ISDN-(Integrated Services Digital Network)-Karte oder ein Modem handelt, eine Datenkommunikationsverbindung mit der entsprechenden Art von Telefonleitung bereit, welche Teil der Netzwerkverbindung 221 ist. Wenn die Kommunikationsschnittstelle 220 eine LAN-(Local Area Network)-Karte ist, dann stellt die Kommunikationsschnittstelle 220 eine Datenkommunikationsverbindung über die Netzwerkverbindung 221 zu einem kompatiblen LAN bereit. Auch drahtlose Verbindungen sind möglich. In allen derartigen Umsetzungen sendet oder empfängt die Kommunikationsschnittstelle 220 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme tragen, welche für verschiedene Arten von Informationen stehen.
Die Netzwerkverbindung 221 stellt in der Regel über ein oder mehrere Netzwerke Datenkommunikationen zu anderen Datenvorrichtungen bereit. Beispielsweise kann eine Netzwerkverbindung 221 eine Verbindung über ein lokales Netzwerk 222 zu einem Hostcomputer 223 oder zu durch einen Internet-Service-Provider-(ISP) 224 betriebenen Datengeräten bereitstellen. Der ISP 224 stellt wiederum Datenkommunikationsdienste durch das World-Wide-Packet-Data-Kommunikationsnetzwerk bereit, das heute allgemein als „Internet" 225 bezeichnet wird. Das lokale Netzwerk 222 und das Internet 225 verwenden beide elektrische, elektromagnetische oder optische Signale, die digitale Datenströme tragen. Die Signale durch die verschiedenen Netzwerke und die Signale auf der Netzwerkverbindung 221 und durch die Kommunikationsschnittstelle 220, die die digitalen Daten zu und von dem Computer 200 tragen, sind beispielhafte Formen von Trägerwellen, die die Informationen transportieren.
Der Computer 200 kann über das/die Netzwerk/Netzwerke, die Netzwerkverbindung 221 und die Kommunikationsschnittstelle 220 Nachrichten senden und Daten, einschließlich eines Programmcodes, empfangen. In dem Internet-Beispiel könnte der Server 226 einen angeforderten Code für ein Anwendungsprogramm über das Internet 225, ISP 224, das lokale Netzwerk 222 und die Kommunikationsschnittstelle 220 übermitteln. Erfindungsgemäß ist eine derartige heruntergeladene Anwendung die beschriebene Vorrichtung zum Vorverarbeiten und Paketieren von Class-Dateien.
Der empfangene Code kann wie er empfangen wird von CPU 213 ausgeführt und/oder für die spätere Ausführung in einem Massenspeicher 212 oder in einem anderen nichtflüchtigen Speicher gespeichert werden. Auf diese Weise kann der Computer 200 einen Anwendungscode in Form einer Trägerwelle erhalten.
Die oben beschriebenen Computersysteme sind in jedem Fall nur exemplarisch gedacht. Eine Ausführungsform der Erfindung kann in jeder Art von Computersystem oder Programmierungs- oder Verarbeitungsumgebung umgesetzt werden.
Class-Datei-Struktur
Die Ausführungsformen der Erfindung sind unter Bezug auf Aspekte des Class-Datei-Format leichter verständlich. Im folgenden wird das Java-Class-Datei-Format beschrieben. Als Anhang A beigefügt ist dieser Beschreibung außerdem das Kapitel 4 „The Class File Format" und das Kapitel 5 „Constant Pool Resolution", aus The Java Virtual Machine Specification, von Tim Lindholm und Frank Yellin, hrsg. Von Addision-Wesley, September 1996 ^©Sun Microsystems, Inc.
Die Java-Klassen-Datei besteht aus einer Kette von 8-Bit-Bytes, mit 16-Bit-, 32-Bit und 64-Bit-Strukturen, die aus aufeinanderfolgenden 8-Bit-Bytes bestehen. Die Class-Datei enthält eine einzelne Klasse oder Schnittstellen-Datei-Struktur. Die Class-Datei-Struktur stellt sich wie folgt dar:
wobei u2 und u4 sich auf vorzeichenlose Zwei-Byte- und Vier-Byte-Größen beziehen. Diese Struktur wird in 3 graphisch dargestellt.
Die Class-Datei 300 in 3 umfaßt Folgendes: Vier-Byte-Magic-Value 301, Zwei-Byte-Minor-Versionsnummer 302, Zwei-Byte-Major-Versionsnummer 303, Zwei-Byte-Konstanten-Pool-Zählwert 304, Konstanten-Pool-Tabelle 305, die der Konstanten-Pool-Anordnung von Elementen variabler Länge entspricht, Zwei-Byte-Zugriffs-Flag-Wert 306, Zwei-Byte-„Diese Klasse"-Kennung 307, Zwei-Byte-Super-Class-Kennung 308, Zwei-Byte-Schnittstellen-Zählwert 309, Schnittstellentabelle 310, die der Schnittstellenanordnung von Zwei-Byte-Elementen entspricht, Zwei-Byte-Feld-Zählwert 311, Feldtabelle 312, die der Feldanordnung von Elementen variabler Länge entspricht, Zwei-Byte- Methoden-Zählwert 313, Methodentabelle 314, die der Methodenanordnung der Elemente variabler Länge entspricht, Zwei-Byte-Attribut-Zählwert 315 und Attributtabelle 316, die der Attributanordnung von Elementen variabler Länge entspricht. Jede der oben genannten Strukturen wird nachstehend kurz erläutert.
Der Magic-Wert 301 enthält eine Zahl, die das Class-Datei-Format identifiziert. Bei dem Java-Class-Datei-Format hat die Magic-Zahl den Wert 0xCAFEBABE. Die Minor-Versionsnummer 302 und die Major-Versionsnummer 303 spezifizieren die Minor- und Majorversionsnummern des für die Erzeugung der Class-Datei verantwortlichen Kompilierers.
Der Konstanten-Pool-Zählwert 304 identifiziert die Anzahl von Einträgen in einer Konstanten-Pool-Tabelle 305. Die Konstanten-Pool-Tabelle 305 ist eine Tabelle mit Datenstrukturen variabler Länge, die verschiedene String-Konstanten, nummerische Konstanten, Klassennamen, Feldnamen und andere Konstanten repräsentieren, auf die innerhalb der Class-Datei-Struktur Bezug genommen wird. Jeder Eintrag in die Konstanten-Pool-Tabelle hat die folgende allgemeine Struktur:
wobei das Ein-Byte-„Tag" eine bestimmte Konstantenart spezifiziert. Das Format der info[]-Anordnung variiert abhängig von der Konstantenart. Die info[]-Anordnung kann ein nummerischer Wert wie für ganze Zahlen oder Floatkonstanten sein, ein Stringwert für Stringkonstanten oder ein Index zu einem anderen Eintrag einer anderen Konstantenart in der Konstanten-Pool-Tabelle. Weitere Einzelheiten der Konstanten-Pool-Tabellenstruktur und der Konstantenarten sind in Kapitel 4 Anhang A ersichtlich.
Der Zugriffs-Flag-Wert 306 ist eine Maske von Modifizierern, die bei Klassen- und Schnittstellenerklärungen verwendet werden. Der „Diese Klasse"-Wert 307 ist ein Index in die Konstanten-Pool-Tabelle 305 zu einer Konstantenartstruktur, die die Klasse oder die durch diese Class-Datei definierte Schnittstelle repräsentiert. Der Super-Class-Wert 308 ist entweder Null, was anzeigt, daß die Klasse eine Unterklasse von java.lang.Objekt ist, oder ein Index in die Konstanten-Pool-Tabelle zu einer Konstantenartstruktur, die die durch diese Class-Datei definierte Schnittstelle repräsentiert.
Der Schnittstellen-Zählwert 309 identifiziert die Anzahl von direkten Super-Schnittstellen dieser Klasse oder Schnittstelle, und entsprechend die Anzahl von Elementen in der Schnittstellen-Tabelle 310. Die Schnittstellen-Tabelle 310 enthält Zwei-Byte-Indizes in die Konstanten-Pool-Tabelle 305. Jeder entsprechende Eintrag in die Konstanten-Pool-Tabelle 305 ist eine Konstantenartstruktur, die eine Schnittstelle repräsentiert, welche eine durch diese Class-Datei definierte direkte Super-Schnittstelle der Klasse oder Schnittstelle repräsentiert.
Der Feld-Zählwert 311 stellt die Anzahl von Strukturen in der Feld-Tabelle 312 bereit. Jeder Eintrag in die Feld-Tabelle 312 ist eine Struktur variabler Länge, die eine Beschreibung eines Felds in der Klassenart bereitstellt. Die Feld-Tabelle 312 enthält nur jede Felder, die von der durch diese Class-Datei definierte Klasse oder Schnittstelle erklärt werden.
Der Methodenzählwert 313 zeigt die Anzahl von Strukturen in der Methodentabelle 314 an. Jedes Element der Methodentabelle 314 ist eine Struktur variabler Länge, die eine Beschreibung und einen Code für eine Virtual-Machine für eine Methode in der Klasse oder Schnittstelle bereitstellt.
Der Attributzählwert 315 gibt die Anzahl von Strukturen in der Attributtabelle 316 an. Jedes Element in der Attributtabelle 31 ist eine Attributstruktur variabler Länge. Die Attributstruktur wird in dem Abschnitt 4.7 von Anhang A erläutert.
Ausführungsformen der Erfindung untersuchen die Konstanten-Pool-Tabelle für jede Klasse in einer Gruppe von Klassen, um zu bestimmen, wo Doppelinformationen bestehen. Beispielsweise kann die Stringkonstante dort, wo zwei oder mehrere Klassen dieselbe Stringkonstante verwenden, aus jeder Class-Datei-Struktur entfernt und in eine gemeinsam genutzte Pool-Tabelle platziert werden. In dem einfachen Fall, wenn N Klassen denselben Konstanteneintrag aufweisen, werden N Einheiten Speicherplatz in den Speicherressourcen aufgenommen. Durch Entfernen aller Konstanteneinträge und Bereitstellen eines gemeinsamen Eintrags, werden N-1 Einheiten Speicherplatz befreit. Die Speicherplatzersparnis steigt mit N. Auch bei der Umsetzung einer gemeinsamen Konstanten-Tabelle müssen Einträge in die Konstanten-Tabelle höchstens einmal vollkommen aufgelöst werden. Nach der Anfangsauflösung können zukünftige Codereferenzen zu der Konstante die Konstante direkt verwenden.
Vorverarbeitung und Paketierung von Klassen
Eine Ausführungsform der Erfindung verwendet einen Klassen-Vorprozessor zum Paketieren von Klassen in einem „mclass"- oder Multi-Class-Datei genannten Format. Ein Verfahren zum Vorverarbeiten und Paketieren einer Gruppe von Class-Dateien wird in dem Flussdiagramm von 4 gezeigt.
Das Verfahren beginnt bei Schritt 400 mit einer Gruppe zufälliger Class-Dateien „S" (in der Regel Teil einer Anwendung). In Schritt 401 liest und analysiert der Vorverarbeiter jede Klasse in „S". In Schritt 402 untersucht der Vorverarbeiter die Konstanten-Pool-Tabellen jeder Klasse, um die Gruppe von Class-Datei-Konstanten (wie Strings und Zahlen und ähnliches für das Class-Datei-Format spezifisches) zu bestimmen, die von den Klassen in „S" gemeinsam genutzt werden kann. Eine gemeinsam genutzte Konstanten-Pool-Tabelle wird in Schritt 403 erstellt, wobei alle doppelten Konstanten aus Schritt 402 bestimmt werden. In Schritt 404 entfernt der Vorprozessor die doppelten, gemeinsam genutzten Konstanten von den einzelnen Konstanten-Pool-Tabellen jeder Klasse.
In Schritt 405 errechnet der Vorprozessor die Kern-Speicher-Erfordernisse jeder Klasse in „S", wie dies normalerweise durch den Class-Loader für die jeweilige Virtual-Machine bestimmt würde. Dies ist die Speichermenge, die eine Virtual-Machine jeder Klasse zuweisen würde, wenn sie jede Klasse einzeln laden würde. Nach Betrachten jeder Klasse in „S" und des zusätzlichen Speichererfordernisses für die gemeinsam benutzte Pool-Tabelle, wird in Schritt 406 das Gesamtspeichererfordernis zum Laden von „S" errechnet.
In Schritt 407 erzeugt der Vorprozessor eine Mehrfach-Klassen(mclass)-Datei, die Folgendes enthält: die in Schritt 403 erzeugte, gemeinsam genutzte Konstanten-Pool-Tabelle, Informationen über in Schritt 405 und 406 bestimmte Speicherzuweisungserfordernisse und alle Klassen in „S" mit ihren jeweils reduzierten Konstanten-Pool-Tabellen. Die mclass-Datei für die Klassengruppe „S" wird in Schritt 408 ausgegeben. In einigen Ausführungsformen kann die Mehrfach-Klassen-Datei komprimiert werden, um die Größe der Mehrfach-Klassen-Datei weiter zu verringern.
Ein Beispiel einer Ausführungsform einer Mehrfach-Klassen-Datei-Struktur kann wie folgt dargestellt werden:
In einer Ausführungsform der Erfindung wird eine neue Konstantenart mit einem entsprechenden Konstantenart-Tag bestimmt. Die neue Konstantenart stellt als ihr info[]-Element einen Index in die gemeinsam genutzte Konstantentabelle bereit. Während der Vorverarbeitung werden doppelte Konstantenelemente in den gemeinsam genutzten Konstanten-Pool als ein gemeinsam genutztes Element platziert und ein Element der neuen Konstantenart ersetzt das doppelte Element im reduzierten Pool zur direkten Aufläsung des gemeinsam genutzten Elements im gemeinsam genutzten Konstanten-Pool. Reduktion tritt auf, weil das Ersatzelement nur ein Zeiger zu der eigentlichen Konstante ist, die im gemeinsam genutzten Konstanten-Pool platziert ist.
5 ist ein vereinfachtes Blockdiagramm einer Ausführungsform des Mehrfach-Klassen-Datei-Formats. Die Mclass-Datei 500 umfaßt die gemeinsam genutzte Pool-Tabelle 501, Speicherzuweisungserfordernisse 502 und die Gruppe einzelner Klassen 503. Die Gruppe einzelner Klassen 503 umfaßt die Class-Datei-Strukturen für die Klassen 1-N (wobei N die Zahl der Klassen in der Gruppe ist), zusammen mit den entsprechenden reduzierten Konstanten-Pool-Tabellen 1-N. Die Größe der gemeinsam genutzten Konstanten-Pool-Tabelle 501 hängt von der der Anzahl der in dieser Gruppe von Klassen gefundenen doppelten Konstanten ab. Die Speicherzuweisungserfordernisse 502 können als ein einziger Wert dargestellt werden, der den für das Laden aller Klassenstrukturen (Klassen 1-N) in einzelne Klassen 503 sowie die gemeinsam genutzte Konstanten-Pool-Tabelle 501 benötigten Gesamtspeicher anzeigt. Der Zähler des gemeinsam genutzten Pools und der Zähler der Class-Datei (in 5 nicht gezeigt) kennzeichnen die Anzahl von Elementen in der gemeinsam genutzten Konstanten-Pool-Tabelle 501 und der Class-Datei-Anordnung von Class-Datei-Strukturen (durch Klassen 503 repräsentiert).
Die Mehrfach-Class-Datei ist in der Regel erheblich kleiner als die Summe der Größen der einzelnen Class-Dateien, aus der sie abgeleitet wurde. Sie kann durch die Virtual-Machine während oder vor der Ausführung einer Anwendung geladen werden, statt jede enthaltene Klasse nach Bedarf zu laden. Die Virtual-Machine ist auch in der Lage, die Informationen über das Zuweisungserfordernis zu nutzen, um allen für die Mehrfach-Klassen-Gruppe benötigten Speicherplatz vorher zuzuweisen. Dies löst viele der mit dem Klassen-Laden verbundenen Probleme.
Klassen in einer Mehrfach-Klassen-Gruppe teilen Informationen untereinander und sind daher kleiner. Dies bietet die folgenden Vorteile:

a) Die Klassen nehmen auf Servern oder Speichergeräten weniger Platz in Anspruch;
b) die Klassen beanspruchen zum Lesen weniger Netzwerk- oder Dateiübertragungszeit;
c) die Klassen beanspruchen beim Laden weniger Speicherplatz; und
d) die Ausführung ist schneller, da gemeinsam genutzte Konstanten höchstens einmal gelöst werden.

Mehrfach-Klassen-Gruppen konsolidieren das Laden der benötigten Klassen anstelle des Ladens der Klassen Klasse für Klasse. Mit Hilfe von Zuweisungsinformationen wird nur eine Zuweisung dynamischen Speichers benötigt anstelle von Mehrfachzuweisungsoperationen. Dies führt zu geringerer Fragementierung, weniger im Zuweiser verbrachte Zeit und weniger Verschwendung von Speicherplatz.
Da die Class-Dateien in einer einzigen Mehrfach-Klassen-Datei konsolidiert sind, wird nur eine einzige Transaktion benötigt, um eine Netzwerk- oder Dateisystemsuche auszuführen, eine Übertragungssitzung (z.B. HTTP) aufzustellen und die gesamte Gruppe von Klassen zu übertragen. Dies minimiert Pausen in der Ausführung, die aus solchen Transaktionen entstehen können und gewährleistet eine deterministische Ausführung ohne Pausen zum Klassenladen während eines Programmdurchlaufs. Außerdem muss der Computer, der das Programm ausführt, nicht mit der Quelle der Klassen verbunden bleiben, sobald die Mehrfach-Klassen-Datei geladen und analysiert ist.
6 veranschaulicht Runtime-Daten-Gebiete der Virtual-Machine, wenn eine Mehrfach-Klassen-Datei gemäß einer Ausführungsform der Erfindung verarbeitet und geladen wird. In 6 umfassen Runtime-Daten-Gebiete 600 Mehrfach-Programm-Zähler-Register (PC REG 1-M) und Mehrfachstapel 1-M. Ein Programmzählerregister und ein Stapel sind jedem in der Virtual-Machine ausgeführten Thread zugewiesen. Jedes Programmzählerregister enthält die Adresse der Virtual-Machine-Anweisung für die aktuelle, von dem jeweiligen Thread ausgeführte Methode. Die Stapel werden von den jeweiligen Threads ausgeführt, um lokale Variablen, Teilergebnisse und einen Operandenstapel zu speichern.
Runtime-Daten-Gebiete 600 umfassen weiterhin den Heap 601, der das Methodengebiet 602 enthält. Der Heap 601 ist das Runtime-Daten-Gebiet, aus dem Speicher für alle Klasseninstanzen und Anordnungen zugewiesen wird. Das Methodengebiet 602 wird unter allen Threads geteilt und speichert Klassenstrukturen, wie Konstanten-Pool, Feld- und Methodendaten und den Code für die Methoden. Innerhalb des Methodengebiets 602, wird der Speicherblock 603, der zusammenhängend oder nicht zusammenhängend sein kann, der Mehrfachklassengruppe der Klassen „S" zugeordnet. Andere Gebiete im Heap 601 können ebenfalls „S" zugeordnet werden. Die reduzierten Konstanten-Pools 1-N befinden sich zusammen mit dem gemeinsam genutzten Konstanten-Pool 604 in Block 603.
Aufgrund des Entfernens redundanter Konstanten gemäß einer Ausführungsform der Erfindung ist die Größe von Block 603, die zum Enthalten reduzierter Konstanten-Pools 1-N und gemeinsam genutzter Konstanen-Pools 604 benötigt wird, viel kleiner, als nötig wäre, um die Konstanten-Pools 1-N aufzunehmen, wenn sie nicht reduziert wären. Die Zuweisungen in Block 603 sind auch weniger fragmentiert (und können im Speicher zusammenhängend vorgefunden werden) als der Speicher, der zugewiesen werden würde, wenn die Klassen einzeln geladen werden würden.
Es wurde also ein Verfahren und eine Vorrichtung zum Vorverarbeiten und Paketieren von Class-Dateien in Verbindung mit einer oder mehreren spezifischen Ausführungsformen beschrieben. Die Erfindung wird durch die Ansprüche und ihren vollen Umfang von Äquivalenten definiert.
Die in der oben stehenden Beschreibung, den Ansprüchen und/oder den angefügten Zeichnungen offenbarten Merkmale können, sowohl einzeln oder in jeder Kombination für die Umsetzung der Erfindung in verschiedenen Formen entscheidend sein.

Claims

Verfahren zur Vorverarbeitung von Class-Dateien, umfassend: Bestimmen (402) mehrerer doppelter Elemente in mehreren Class-Dateien; Bilden (403) einer zwischen den Class-Dateien gemeinsam geteilten Tabelle, welche die mehreren doppelten Elemente umfaßt; Entfernen (404) der doppelten Elemente aus den mehreren Class-Dateien, um mehrere reduzierte Class-Dateien zu erhalten; und Bilden (407) einer Multi-Class-Datei, die die mehreren reduzierten Class-Dateien und die gemeinsame Tabelle umfaßt.
Verfahren nach Anspruch 1, das des weiteren umfaßt: Berechnen (405) eines individuellen Speicherzuweisungserfordernisses für jede der mehreren reduzierten Class-Dateien; Berechnen (406) eines Gesamtspeicherzuweisungserfordernisses für die mehreren Class-Dateien aus dem individuellen Speicherzuweisungserfordernis jeder der mehreren reduzierten Class-Dateien; Speichern des Gesamtspeicherzuweisungserfordernisses in der Multi-Class-Datei.
Verfahren nach Anspruch 2, das des weiteren umfaßt: Lesen des Gesamtspeicherzuweisungserfordernisses aus der Multi-Class-Datei; Zuweisen eines Teils eines Speichers basierend auf dem Gesamtspeicherzuweisungserfordernis; und Laden der reduzierten Class-Dateien und der gemeinsamen Tabelle in den Teil des Speichers.
Verfahren nach Anspruch 3, das des weiteren umfaßt: Zugreifen auf die gemeinsame Tabelle im Teil des Speichers, um eines oder mehrere in einer oder mehreren der reduzierten Class-Dateien nicht gefundene Elemente zu erhalten.
Verfahren nach Anspruch 1, wobei der Schritt (402) des Bestimmens mehrerer doppelter Elemente umfaßt: Bestimmen einer oder mehrerer zwischen zwei oder mehreren Class-Dateien gemeinsam geteilter Konstanten.
Verfahren nach Anspruch 5, wobei der Schritt des Bildens (403) einer gemeinsamen Tabelle umfaßt: Bilden einer gemeinsamen Konstanten-Tabelle, die eine oder mehrere zwischen den zwei oder mehreren Class-Dateien gemeinsam geteilte Konstanten umfaßt.
Computerprogrammprodukt, welches umfaßt: ein computernutzbares Medium mit einem darin implementierten computerlesbaren Programmcode zur Vorverarbeitung von Class-Dateien, wobei das Computerprogrammprodukt umfaßt: einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, mehrere doppelte Elemente in mehreren Class-Dateien zu bestimmen (402); einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, eine zwischen den Class-Dateien gemeinsam geteilte Tabelle zu bilden (403), welche die mehreren doppelten Elemente umfaßt: einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, die doppelten Elemente aus den mehreren Class-Dateien zu entfernen (402), um mehrere reduzierte Class-Dateien zu erhalten; einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, eine Multi-Class-Datei zu bilden (407), welche die mehreren reduzierten Class-Dateien und die gemeinsame Tabelle umfaßt.
Computerprogrammprodukt nach Anspruch 7, das des weiteren umfaßt: einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, ein individuelles Speicherzuweisungserfordernis jeder der mehreren reduzierten Class-Dateien zu berechnen (405); einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, ein Gesamtspeicherzuweisungserfordernis der mehreren Class-Dateien aus dem individuellen Speicherzuweisungserfordernis jeder der mehreren reduzierten Class-Dateien zu berechnen (406); und einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, das Gesamtspeicherzuweisungserfordernis in der Multi-Class-Datei zu speichern.
Computerprogrammprodukt nach Anspruch 8, das des weiteren umfaßt: einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, das Gesamtspeicherzuweisungserfordernis aus der Multi-Class-Datei zu lesen; einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, einen Teil eines Speichers basierend auf dem Gesamtspeicherzuweisungserfordernis zuzuweisen; einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, die reduzierten Class-Dateien und die gemeinsame Tabelle in den Teil des Speichers zu laden.
Computerprogrammprodukt nach Anspruch 9, das des weiteren umfaßt: einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, auf die gemeinsame Tabelle in dem Teil des Speichers zuzugreifen, um eines oder mehrere in einer oder mehreren der reduzierten Class-Dateien nicht gefundene Elemente zu erhalten.
Computerprogrammprodukt nach Anspruch 7, wobei der computerlesbare Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, die mehreren doppelten Elemente zu bestimmen (402), umfaßt: einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, eine oder mehrere zwischen zwei oder mehreren Class-Dateien gemeinsam geteilte Konstanten zu bestimmen.
Computerprogrammprodukt nach Anspruch 11, wobei der computerlesbare Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, die gemeinsame Tabelle zu bilden, umfaßt: einen computerlesbaren Programmcode, der konfiguriert ist, einen Computer dazu zu veranlassen, eine gemeinsame Konstanten-Tabelle zu bilden, die die eine oder mehreren zwischen den zwei oder mehreren Class-Dateien gemeinsam geteilten Konstanten umfaßt.
Vorrichtung, umfassend: einen Prozessor; einen mit dem Prozessor gekoppelten Speicher; mehrere im Speicher gespeicherte Class-Dateien; einen auf dem Prozessor ablaufenden Prozeß, wobei der Prozeß konfiguriert ist, eine Multi-Class-Datei zu bilden, die umfaßt: mehrere reduzierte Class-Dateien (503), die aus den mehreren Class-Dateien durch Entfernen eines oder mehrerer Elemente, die in zwei oder mehr der mehreren Class-Dateien doppelt sind, erhalten sind; und eine zwischen den Class-Dateien gemeinsam geteilte Tabelle (501), welche die doppelten Elemente umfaßt.
Vorrichtung nach Anspruch 13, wobei die Multi-Class-Datei des weiteren ein Speichererfordernis (502) umfaßt, wobei das Speichererfordernis durch den Prozeß berechnet wird.
Vorrichtung nach Anspruch 13, wobei die doppelten Elemente Elemente von Konstanten-Datenbasen jeweiliger Class-Dateien umfassen, wobei die gemeinsame Tabelle (501) einen gemeinsamen Konstanten-Pool umfaßt.
Vorrichtung nach Anspruch 13, die des weiteren umfaßt: eine Virtual-Machine mit einem Class-Loader und einem Runtime-Datenbereich, wobei der Class-Loader konfiguriert ist, die Multi-Class-Datei in den Runtime-Datenbereich zu erhalten und zu laden.
Vorrichtung nach Anspruch 16, wobei der Class-Loader konfiguriert ist, einen Teil des Runtime-Datenbereichs basierend auf dem Speichererfordernis (502) in der Multi-Class-Datei zuzuweisen.
Vorrichtung nach Anspruch 17, wobei der Class-Loader konfiguriert ist, die mehreren reduzierten Class-Dateien (503) und die gemeinsame Tabelle (501) in den Teil des Runtime-Datenbereichs zu laden.
Vorrichtung nach Anspruch 16, wobei die Virtual-Machine konfiguriert ist, auf die gemeinsame Tabelle (501) zuzugreifen, wenn ein gewünschtes mit einer ersten Class-Datei in Verbindung stehendes Element nicht in einer entsprechenden der mehreren reduzierten Class-Dateien (503) vorhanden ist.
Vorrichtung nach einem der Ansprüche 13 bis 19, umfassend einen Speicher, der konfiguriert ist, Daten für einen Zugriff durch eine Virtual-Machine, die in einem Computersystem ausführt, zu speichern, wobei der Speicher umfaßt: eine im Speicher gespeicherte Datenstruktur, wobei die Datenstruktur umfaßt: mehrere reduzierte Class-Dateien (503), die mit mehreren entsprechenden Classes zusammenhängen, wobei die mehreren reduzierten Class-Dateien (503) konfiguriert sind, durch die Virtual-Machine zur Ausführung der mehreren Classes geladen zu werden; eine zwischen den Class-Dateien gemeinsam geteilte Tabelle (501), die eines oder mehrere Elemente umfaßt, die in zwei oder mehreren der mehreren Classes doppelt sind, wobei die gemeinsame Tabelle (501) konfiguriert ist, in die Virtual-Machine geladen zu werden, damit darauf für die doppelten Elemente zugegriffen werden kann; und einen Speichererforderniswert (502), der konfiguriert ist, durch einen Class-Loader der Virtual-Machine gelesen zu werden, um einen Teil eines Runtime-Datenbereichs zum Laden der mehreren reduzierten Class-Dateien (503) und der gemeinsamen Tabelle (501) zuzuweisen.
Vorrichtung nach Anspruch 20, wobei die doppelten Elemente aus den mehreren reduzierten Class-Dateien (503) entfernt sind.
Vorrichtung nach Anspruch 20, wobei die doppelten Elemente Konstanten aufweisen und die gemeinsame Tabelle (501) einen gemeinsamen Konstanten-Pool aufweist.
Vorrichtung nach Anspruch 20, wobei der Speichererforderniswert (502) aus individuellen Speichererfordernissen der mehreren reduzierten Class-Dateien (503) und einem Speichererfordernis der gemeinsamen Tabelle (501) berechnet wird.