-
Die
Erfindung betrifft ein Verfahren zum Optimieren von Programmcode für
einen tragbaren Datenträger mit mindestens zwei virtuellen
Ausführungseinheiten, insbesondere zwei virtuelle Maschinen,
sowie eine entsprechende Vorrichtung und einen entsprechenden Datenträger.
-
Tragbare
Datenträger mit einer virtuellen Maschine zur Programmausführung
sind aus dem Stand der Technik gut bekannt. Beispielsweise werden
in Kapitel 5.14.1 des Buchs „Handbuch der Chipkarten" von
W. Rankl und W. Effing, Hanser Verlag, 4. Auflage, 2002, Seiten
308 bis 328, Datenträger nach der Java-Card-Spezifikation
beschrieben. Diese Datenträger enthalten eine virtuelle
Java-Card-Maschine, die auch als JCVM-Maschine bekannt ist (JCVM
= Java Card Virtual Machine). Die virtuellen Maschinen solcher Datenträger
führen Programme basierend auf sogenanntem Java-Bytecode
aus, wobei mittlerweile verschiedene Versionen dieses Bytecodes
bekannt sind. Insbesondere existiert Bytecode gemäß Java
2.2, der auf virtuellen 16-Bit-Maschinen ausgeführt werden
kann, sowie Java-Bytecode gemäß Java 3.0, der
zur Ausführung auf virtuellen 32-Bit-Maschinen vorgesehen
ist.
-
Aufgrund
der wachsenden Anzahl von verschiedenen Java-Bytecodes besteht das
Problem, dass eine optimierte Ausführung der Bytecodes durch
eine einzelne virtuelle Ausführungseinheit auf einem tragbaren
Datenträger nicht gewährleistet werden kann. Gemäß der
Druckschrift
WO 2005/069136
A1 wird deshalb vorgeschlagen, auf einem tragbaren Datenträger
eine virtuelle Maschine mit unterschiedliche Implementierungen vorzusehen, zwischen
denen durch Steuerbefehle im Programmcode gewechselt wird. Insbesondere
wird vorgeschlagen, mehrere voneinander getrennte Versionen von Codeinterpretern
in einer virtuellen Maschine einzusetzen, wobei jeder Codeinterpreter
den Programmcode auf unterschiedliche Weise ausführt. Die aus
WO 2005/069136 A1 bekannter
Lösung erlaubt eine an bestimmte Vorgaben anpaßbare
Ausführung eines Programmcodes durch unterschiedliche virtuelle
Ausführungseinheiten. Die Anpassung muß aber durch
entsprechende Steuerbefehle vorab festgelegt werden. Für
eine Optimierung eines an sich fertigen Programmcodes nach dessen
Erstellung ist die Lösung nicht geeignet.
-
Aufgabe
der Erfindung ist es deshalb, den Programmcode für einen
tragbaren Datenträger mit mehreren virtuellen Ausführungseinheiten
im Hinblick auf vorbestimmte Kriterien zu optimieren.
-
Diese
Aufgabe wird durch das Verfahren gemäß Anspruch
1, die Vorrichtung gemäß Anspruch 18 sowie die
tragbaren Datenträger gemäß Anspruch 19
und 20 gelöst. Weiterbildungen der Erfindung sind in den
abhängigen Ansprüchen definiert.
-
Die
Erfindung beruht auf der Idee, Programmcode für einen tragbaren
Datenträger mit einer ersten und zweiten virtuellen Ausführungseinheit, insbesondere
in der Form von virtuellen Maschinen, im Hinblick auf vorbestimmte
Kriterien zu analysieren und in optimierten Programmcode zu transformieren. Der
zu optimierende Programmcode enthält dabei erste, auf der
ersten virtuellen Ausführungseinheit ausführbare
Codeelemente, und es werden erfindungsgemäß in
diesem Programmcode solche Codeelemente als optimierbare Codeelemente
bestimmt, welche ein oder mehrere Optimierungskriterien erfüllen.
Diese ersten optimierbaren Codeelemente werden dann in zweite Codeelemente
transformiert, wobei die zweiten Codeelemente auf der zweiten virtuellen
Ausführungseinheit ausführbar sind. Der Pro grammcode,
der die (nicht optimierbaren) ersten Codeelemente und die transformierten
zweiten Codeelemente enthält, stellt somit den optimierten
Programmcode dar.
-
Erfindungsgemäß wird
somit eine effiziente Verwendung von zwei unterschiedlichen Ausführungseinheiten
bei der Ausführung eines Programmcodes dadurch ermöglicht,
dass bei Vorliegen bestimmter Optimierungskriterien Codeelemente,
welche ursprünglich für die Ausführung
auf der ersten Ausführungseinheit gedacht waren, in Codeelemente zur
optimierten Ausführung auf der zweiten Ausführungseinheit
transformiert werden. Die Optimierungskriterien können
hierbei beliebig festgelegt sein, entscheidend ist lediglich, dass
die Kriterien aus den Codeelementen ermittelbar sind. Vorzugsweise
sollte eine Transformation eines ersten Codeelements, welches die
Optimierungskriterien erfüllt, zu einem Effizienzgewinn
im Hinblick auf Laufzeit und Speicherbedarf bei der Ausführung
des transformierten Codeelements mit der zweiten Ausführungseinheit
führen.
-
In
einer bevorzugten Ausführungsform der Erfindung ist der
Programmcode ein Java-Bytecode, und bei den Ausführungseinheiten
handelt es sich um JVM-Maschinen (JVM = Java Virtual Machine), insbesondere
um sogenannte JCVM-Maschinen (JCVM = Java Card Virtual Machine).
Vorzugsweise ist dabei die erste Ausführungseinheit eine 32-Bit-JVM-Maschine
bzw. JCVM-Maschine und die zweite Ausführungseinheit ist
eine 16-Bit-JVM-Maschine bzw. JCVM-Maschine, wobei die ersten Codeelemente
aus 32-Bit-Java-Bytecode und die zweiten Codeelemente aus 16-Bit-Java-Bytecode
bestehen. Hierbei macht man sich die Erkenntnis zunutze, dass 32-Bit-Java-Bytecode
oftmals Anwendungen betrifft, welche ursprünglich für
16-Bit-JVM-Maschinen vorgesehen waren, so dass unter bestimmten
Umständen ein Programm effizienter ausgeführt
werden kann, wenn der entsprechende 32- Bit-Java-Bytecode in den
16-Bit-Java-Bytecode umgewandelt wird. Die Ausführungseinheiten
können sich jedoch auch basierend auf anderen Kriterien
unterscheiden, z. B. basierend auf dem Instruktionssatz, den Datentypen,
den Sicherheitsrichtlinien oder einer Kombination dieser Merkmale.
Vorzugsweise sollte jedoch eine optimierte Ausführungszeit
bzw. reduzierter Speicherbedarf bei der Ausführung der
zweiten Codeelemente auf der zweiten Ausführungseinheit
erreicht werden.
-
Vorzugsweise
stellen die ersten bzw. zweiten Codeelemente jeweils Methoden in
Java-Bytecode dar. Ferner ist das Verfahren vorzugsweise derart ausgestaltet,
dass bei der Ausführung des optimierten Programmcodes ein
einheitlicher Java-Stack für die ersten und zweiten Codeelemente
verwendet wird. Zur Unterscheidung der Codeelemente werden die zweiten
Codeelemente vorzugsweise mit einem Header versehen, der die Ausführung
des jeweiligen Codeelements auf der zweiten virtuellen Ausführungseinheit
anzeigt.
-
Wie
bereits dargelegt, können die Optimierungskriterien beliebig
gewählt sein. Beispielsweise können sie von der
Art der durch das jeweilige erste Codeelement durchgeführten
Anwendung abhängen. In einer Ausführungsform der
Erfindung wird bei der Verwendung von Java-Bytecode ein jeweiliges erstes
Codeelement einer Anwendung vom Legacy-Typ im zu optimierenden Programmcode
bei der Analyse des Programmcodes als erstes optimierbares Codeelement
bestimmt. Ebenso ist es möglich, dass ein erstes Codeelement
im zu optimierenden Programmcode, welches das TCP/IP-Protokoll nutzt (TCP
= Transmission Control Protocol; IP = Internet Protocol) und neben
der Nutzung dieses Protokolls zumindest ein weiteres Optimierungskriterium
erfüllt, bei der Analyse des Programmcodes als erstes optimierbares
Codeelement bestimmt wird. Darüberhinaus kann ein Optimie rungskriterium
für alle oder zumindest einen Teil der ersten Codeelemente
die Größe des jeweiligen ersten Codeelements betreffen, wobei
erste Codeelemente ab einer bestimmten Codegröße
bei der Analyse des Programmcodes nicht als optimierbare erste Codeelemente
bestimmt werden.
-
Vorzugsweise
ist der zu optimierende Programmcode für einen nicht-flüchtigen
Speicher auf dem tragbaren Datenträger vorgesehen. Dabei
wird beim oder nach dem Laden des Programmcodes in den nicht-flüchtigen
Speicher des tragbaren Datenträgers die erfindungsgemäße
Programmcode-Analyse durchgeführt. Nach der Analyse werden
die ermittelten ersten, optimierbaren Codeelemente vor deren ersten
Ausführung in einen Arbeitsspeicher des tragbaren Datenträgers übertragen,
wobei während und nach der Übertragung diese Codeelemente in
die jeweiligen zweiten Codeelemente transformiert werden und im
Arbeitsspeicher temporär gespeichert werden. Durch die
Zwischenspeicherung im Arbeitsspeicher wird ein Test der zweiten
Codeelemente dahingehend ermöglicht, ob die Ausführung
dieser Codeelemente tatsächlich zu einem Effizienzgewinn führt.
Dieser Test besteht darin, dass nach der ersten Ausführung
der in dem Arbeitsspeicher gespeicherten zweiten Codeelemente eine
Analyse durchgeführt wird, durch welche bestimmt wird,
ob die Ausführung der zweiten Codeelemente ein oder mehrere Effizienzkriterien
erfüllt. Zusätzlich wird dabei die konkrete Ausführung
der Codeelemente verifiziert. Nur diejenigen zweiten Codeelemente,
deren Ausführung die Effizienzkriterien erfüllen,
werden dann permanent in den nicht-flüchtigen Speicher
kopiert und ersetzen dort die ursprünglichen jeweiligen
ersten Codeelemente.
-
Die
Effizienzkriterien, welche nach der ersten Ausführung der
zweiten Codeelemente im Arbeitsspeicher berücksichtigt
werden, können beispielsweise die Ausführungszeitdauer
eines jeweiligen zweiten Codeelements umfas sen, wobei im Falle, dass
die Ausführungszeitdauer unterhalb einer vorgegebenen Schwelle
liegt, das jeweilige zweite Codeelement in den nicht-flüchtigen
Speicher kopiert wird, um das entsprechende erste Codeelement zu ersetzen.
Es können auch andere Effizienzkriterien alternativ oder
zusätzlich herangezogen werden, beispielsweise auch der
Speicherplatzbedarf bei der Ausführung des Codes.
-
Anstatt
des oben beschriebenen Verfahrens, bei dem zweite Codeelemente zunächst
im Arbeitsspeicher zwischengespeichert werden, kann erfindungsgemäß auch
sofort eine Umsetzung der optimierbaren ersten Codeelemente in zweite
Codeelemente ohne Zwischenspeicherung erfolgen. In diesem Fall wird
analog zum vorangegangenen Verfahren beim oder nach dem Laden des
Programmcodes in den nicht-flüchtigen Speicher des tragbaren
Datenträgers die Analyse des Programmcodes durchgeführt,
wobei nunmehr jedoch die ersten Codeelemente unmittelbar (d. h.
ohne Zwischenspeicherung) in die zweiten Codeelemente transformiert
werden und in dem nicht-flüchtigen Speicher gespeichert werden,
um dort die entsprechenden ersten Codeelemente zu ersetzen.
-
In
einer weiteren Ausführungsform des erfindungsgemäßen
Verfahrens ist der zu optimierende Programmcode nicht für
einen nicht-flüchtigen Speicher auf dem tragbaren Datenträger
vorgesehen, sondern es handelt sich um vorab installierte Applikationen
für ein maskenprogrammiertes ROM auf dem tragbaren Datenträger.
In diesem Fall erfolgt die Transformation entsprechender Codeelemente
außerhalb des tragbaren Datenträgers bei der Generierung
des maskenprogrammierten ROMs.
-
Die
Erfindung betrifft ferner eine Vorrichtung zur Optimierung von Programmcode
für einen tragbaren Datenträger mit mindestens
zwei unter schiedlichen virtuellen Ausführungseinheiten,
wobei die Vorrichtung einen Prozessor und zumindest einen Speicher
umfasst und der Speicher Befehle enthält, die dem Prozessor
zur Ausführung des oben beschriebenen erfindungsgemäßen
Verfahrens veranlassen. Diese Vorrichtung kann insbesondere Bestandteil
des Datenträgers sein, für den der zu optimierende
Programmcode vorgesehen ist. In diesem Fall ist der Prozessor ein
Mikroprozessor auf dem Datenträger und der Speicher ist
ein Speicher auf dem Datenträger.
-
Die
Erfindung umfasst ferner einen tragbaren Datenträger mit
zumindest zwei virtuellen Ausführungseinheiten, wobei auf
dem Datenträger Programmcode gespeichert ist, der mit dem
erfindungsgemäßen Verfahren optimiert worden ist.
-
Ausführungsbeispiele
der Erfindung werden nachfolgend anhand der beigefügten
Figuren detailliert beschrieben.
-
Es
zeigen:
-
1 eine
schematische Darstellung der wesentlichen Komponenten einer Chipkarte
gemäß einer Ausführungsform der Erfindung;
-
2 eine
schematische Darstellung des Ablaufs einer Ausführungsform
des erfindungsgemäßen Verfahrens zum Optimieren
von Programmcode.
-
1 zeigt
in schematischer Darstellung einen tragbaren Datenträger
in der Form einer Chipkarte 1, wobei lediglich diejenigen
Komponenten wiedergegeben sind, welche für das erfindungsgemäße Verfahren
wesentlich sind. Bei dem in 1 gezeigten
Datenträger handelt es sich um eine Chipkarte gemäß der
Java-Card-Spezifikation. Der Datenträger umfasst auf einem
einzigen Halbleiterchip einen Mikroprozessor 2, der mit
einem Arbeitsspeicher in der Form eines RAMs 3, einem Festwertspeicher
in der Form eines maskenprogrammierten ROMs 4 sowie einem
nicht-flüchtigen Speicher in der Form eines elektrisch
lösch- und programmierbaren EEPROM wechselwirkt. Diese
Wechselwirkung wird gemäß 1 durch
entsprechende Pfeile A1, A2 und A3 schematisch angedeutet.
-
Über
eine (nicht gezeigte) Schnittstellenschaltung kann Programmcode
in der Form von Java-Bytecode in den nicht-flüchtigen Speicher 5 der Chipkarte 1 geladen
werden. Entsprechend geladener Code ist in 1 mit dem
Bezugszeichen 51 angedeutet, wobei dieser Code gegebenenfalls
bereits basierend auf dem erfindungsgemäßen Verfahren optimiert
sein kann. Zur Ausführung des Programmcodes 51 sind
in der Chipkarte 1 in dem Festwertspeicher 4 zwei
virtuelle Java-Card-Maschinen 41 und 42 vorgesehen.
Jede dieser virtuellen Maschinen enthält einen (nicht gezeigten)
Codeinterpreter sowie ein Sicherheitsmodul. Ferner ist in dem Speicher 4 eine
(nicht gezeigte) Klassenbibliothek für die virtuellen Maschinen
vorgesehen, welche eine Reihe vordefinierter Anwendungs-Programmierschnittstellen
beschreibt. Mit Hilfe der Codeinterpreter der virtuellen Maschinen 41 und 42 wird
Java-Bytecode durch die virtuellen Maschinen ausgeführt.
-
In
der Ausführungsform der 1 unterscheiden
sich die beiden virtuellen Maschinen 41 und 42 dahingehend,
dass es sich bei der Maschine 41 um eine virtuelle 32-Bit-Maschine
handelt, die als Standarddatentyp Daten von 32 Bit Breite verwendet und
die 32-Bit-Java-Bytecode gemäß Java Card 3.0 ausführen
kann, wohingegen die virtuelle Maschine 42 eine virtuelle
16-Bit-Maschine ist, die als Standarddatentyp Daten von 16 Bit Breite
verwendet und die 16-Bit-Java-Bytecode gemäß Java
Card 2.2 ausführen kann. Basierend auf den unterschiedlichen verarbeiteten
Standarddatentypen bestehen zwischen den beiden Maschinen erhebliche
Unterschiede. So ist naturgemäß vor allem der
Befehlsumfang der 32-Bit Maschine deutlich größer
als der der 16-Bit Maschine. Die Maschinen 41 und 42 unterscheiden sich
weiter grundsätzlich in der Art der Adressierung. Die 16-Bit-Maschine
nutzt als Linkinformationen, d. h. Referenzen auf andere Codeteile,
z. B. Methoden, Klassen, Felder, etc., Token, die die Form von 16
Bit Bezeichnern (identifier) haben. In einer 32-BitMaschine ist
die Linkinformation dagegen in Form von eindeutigen Zeichenketten
(Strings) gegeben. Entsprechend den unterschiedlichen Standarddatentypen
unterscheiden sich die beiden Maschinen 41, 42 in
der Speicherverwaltung, insbesondere hinsichtlich der Breite der
Heap- und Stackelemente.
-
Als
Folge des kleineren Befehlsumfangs und der geringeren Größe
der Standarddatentypen benötigt eine 16-Bit Maschine einen
wesentlich kleineren Adreßraum als eine 32-Bit Maschine.
Aufgrund der insgesamt zu bewältigenden kleineren Informationsmenge
erzeugt die 16-Bit Maschine einen im Vergleich zu einer 32-Bit Maschine
geringeren Speicherverbrauch. Alle Faktoren, der kleinere Adreßraum, die
kleinere Datenstruktur, die geringere Informationsmenge führen
dazu, daß eine 16-Bit Maschine grundsätzlich schneller
und effizienter arbeitet als eine 32-Bit-Maschine. Es ist daher
zweckmäßig, Codeelemente, die für eine
Ausführung durch eine 16-Bit Maschine geeignet sind, auch
durch eine solche ausführen zu lassen. Aus diesem Grund
wird ein auf die Karte zu ladender Code dahingehend optimiert, daß in
dem Code enthaltene Codeelemente, die für eine Ausführung
durch eine 16-Bit Maschine geeignet sind, durch die Maschine 41 ausgeführt werden.
-
Der
ursprünglich auf die Karte zu ladende Java-Bytecode enthält
Codeelemente in Java 3.0. Der mit dem erfindungsgemäßen
Verfahren optimierte Code enthält hingegen sowohl 32-Bit-Code
als auch 16-Bit-Code. Bei der Ausführung des optimierten Programmcodes
werden in Abhängigkeit davon, ob es sich um 16-Bit-Code
oder 32-Bit-Code handelt, die entsprechenden Methoden entweder durch
die virtuelle Maschine 42 oder durch die virtuelle Maschine 41 durchgeführt.
Bei der Ausführung des Programmcodes wird ein einheitlicher
Java-Stack 31 im RAM 3 angelegt, wobei dieser
Java-Stack von beiden virtuellen Maschinen verwendet wird. Ferner
ist ein sog. Heap 52 im nicht-flüchtigen Speicher 5 vorgesehen, auf
den die virtuellen Maschinen 41 und 42 zugreifen. Die
entsprechenden Wechselwirkungen zwischen den einzelnen Komponenten
in den Speichern 3, 4 und 5 sind in 1 schematisch
durch Doppelpfeile angedeutet, die aus Übersichtlichkeitsgründen
nicht mit Bezugszeichen versehen sind.
-
Die
Optimierung des ursprünglichen Programmcodes in Java 3.0
erfolgt in der nachfolgend anhand von 2 beschriebenen
Ausführungsform in einem Just-in-Time-Verfahren, bei dem
unmittelbar vor der erstmaligen Ausführung eines Codeelements,
welches durch eine Optimierungsfunktion analysiert und als optimierbar
eingestuft wurde, die entsprechende Optimierung des Segments durchgeführt
wird. In 2 sind die einzelnen Schritte
einer entsprechenden Programmcode-Analyse verdeutlicht. Der Programmcode
wird dabei methodenweise basierend auf den einzelnen Methoden im
Java-Bytecode analysiert. Zunächst liegt nur Java-Bytecode
in Java 3.0 zur Ausführung durch die virtuelle Maschine 41 vor.
In 2 sind beispielhaft zwei Methoden A und B dieses
Java-Bytecodes wiedergegeben, wobei in 2 der Teil
des Diagramms links der Linie L den nicht-flüchtigen Speicher 5 repräsentiert,
wohingegen der Teil rechts der Linie L das RAM 3 wiedergibt.
-
Bei
der Programmcode-Analyse wird nunmehr nach vorgegebenen Optimierungskriterien
ermittelt, ob die entsprechende Methode dahingehend optimierbar
ist, dass eine Wandlung des Bytecodes für Java 3.0 in einen
Bytecode für Java 2.2 zu einem Effizienzgewinn bei der
Ausführung des gewandelten Codes durch die virtuelle 16-Bit-Maschine 42 führt.
-
Derzeit
erfolgt auf dem Gebiet der Karten ein Übergang von virtuellen
16-Bit-Maschinen auf virtuelle 32-Bit-Maschinen, so dass Java-Bytecode
für virtuelle 32-Bit-Maschinen oftmals aus entsprechend angepassten
Anwendungen hervorgeht, die ursprünglich für virtuelle
16-Bit-Maschinen gedacht waren. Es existieren deshalb in 32-Bit-Java-Bytecode häufig
Codeelemente, deren Ausführung auf einer 32-Bit Maschine
welche zu einem Effizienzverlust ei der Ausführung im Vergleich
zu einer Ausführung auf einer 16-Bit Maschine führen.
Ein solcher Effizienzverlust resultiert beispielsweise daraus, dass
im ursprünglichen Bytecode gemäß Java
2.2 zur Umwandlung in Java 3.0 eine Vielzahl von „0" eingefügt werden
muss oder im 16-Bit-Bereich kompakte Befehle zu komplexen Kommandofolgen
in der 32-Bit-Technik führen. Beispielsweise wird der Befehl „sadd",
welcher in 16-Bit Technik der Addition zweier Werte vom Typ short
entspricht, aufgrund des für den 32-Bit-Bereich definierten
Default-Typs 32-Bit Integer zu der Folge „i2s a", „i2s
b", „iadd", „i2s c". Der Befehl „i2s
a" wandelt hierbei den Wert a in den Typ short, der Befehl „i2s
b" wandelt b in den Typ short, der Befehl „iadd" addiert
zwei Integer-Werte, und der Befehl „i2s c" wandelt das
Ergebnis c dieser Addition wiederum in den Typ short.
-
Um
den oben beschriebenen Effizienzverlust zu vermeiden, werden deshalb
die einzelnen Methoden im Java-Bytecode im Hinblick auf ihre Optimierbarkeit
analysiert, wobei geeignete Optimierungskriterien vorgegeben werden.
-
Ein
Optimierungskriterium kann dabei die Art der Anwendung sein. In
einer bevorzugten Variante werden beispielsweise Applikationen vom „Legacy"-Typ
immer als optimierbar eingestuft. Demgegenüber werden Methoden,
welche Code-Elemente enthalten, die auf die Nutzung des TCP/IP-Protokolls schließen
lassen, nur dann als optimierbar eingestuft, wenn weitere Optimierungskriterien
dafür sprechen. Weitere Optimierungskriterien können
beispielsweise die Größe einer Methode sein, da
zu große Methoden oder Methoden mit komplexen Instruktionen
nur aufwendig oder gar nicht optimiert werden können. Der
Applikationstyp ist in den einzelnen Methoden dabei regelmäßig
in irgendeiner Form in der Applikation codiert, beispielsweise als
Eintrag in einer XML-Deskriptor-Datei. Ferner können auch
die verwendeten Datentypen in den Optimierungskriterien berücksichtigt
werden.
-
Ein
notwendiges Kriterium für eine Optimierung ist ferner der
Test, ob sich ein für eine Optimierung in Betracht gezogenes
Codeelement auf den – kleineren – Adreßraum
abbilden läßt, der mit einer 16-Bit Maschine darstellbar
ist. Da sie aufgrund ihres Ursprungs regelmäßig
in dem Adreßraum einer 16-Bit Maschine darstellbar sind,
ist deshalb für solche Codeelemente, die aus ursprünglich
für 16-Bit Maschinen entwickelten Codeelementen hervorgegangen
sind, die erfindungsgemäße Optimierung besonders
effizient.
-
In
dem in 2 gezeigten Szenario wird festgestellt, dass die
Methode A des ursprünglichen 32-Bit-Bytecodes nicht optimierbar
ist, wohingegen die Methode B als optimierbar eingestuft wird. In
der hier beschriebenen Ausführungsform wird nunmehr die
optimierbare Methode B vor der ersten Ausführung temporär
in das RAM 3 kopiert, wobei während des Kopierens
oder unmittelbar danach eine entsprechende Transformation der Methode
B in Java-Bytecode gemäß Java 2.2 zur Ausführung
auf der 16-Bit-Maschine 42 transformiert wird. Der Kopier- und
Transformationsvorgang ist in 2 durch
einen strichpunktierten Pfeil P1 angedeutet und die transformierte
Methode wird als B' bezeichnet.
-
Die
Transformation der Methode B in die Methode B' läuft derart
ab, dass letztlich die Maßnahmen, mit denen der ursprüngliche
16-Bit-Code in den 32-Bit-Code überführt wurde,
rückgängig gemacht werden. Der Methode B sind
ferner entsprechende Konstantenpooleinträge im Heap 52 zugeordnet, welche
in 2 als CP bezeichnet sind. Bei der Transformation
der Methode B werden auch diese Konstantenpooleinträge
angepasst, indem z. B. Pointer auf die neue Methode B' abgestimmt
werden. Darüber hinaus werden, sofern erforderlich, entsprechende Übergabeparameter
angepasst. Die angepassten Konstantenpooleinträge sind
in 2 mit CP' bezeichnet und werden im RAM 3 zwischengespeichert,
wie durch den strichpunktierten Pfeil P2 angedeutet ist. Zur Unterscheidung
von Methoden im 32-Bit-Code von Methoden im 16-Bit-Code werden die
transformierten Methoden mit entsprechenden Headern versehen.
-
Schließlich
wird die Methode B' im RAM 3 ausgeführt. Dabei
wird überprüft, ob die Optimierung tatsächlich
wirksam ist, d. h. zu einem Effizienzgewinn führt. Dies
kann z. B. durch die Erfassung der Ausführungszeit der
Methode erfolgen. Wird hierbei festgestellt, dass tatsächlich
ein Effizienzgewinn erreicht wird, erfolgt die permanente Speicherung
der Methode B' und der Konstantpooleinträge CP' im nicht-flüchtigen
Speicher 5. Insbesondere werden die Methode B' sowie die
Konstantenpooleinträge CP in den nicht-flüchtigen
Speicher 5 kopiert und ersetzen dort die ursprüngliche
Methode B und die ursprünglichen Konstantenpooleinträge
CP. Dies wird durch die strichpunktierten Pfeile P3 und P4 angedeutet.
-
In 2 ist
ferner der bei der Ausführung der Methoden A bzw. B' verwendete
Java-Stack 31 angedeutet. Durch Linien L1 bzw. L2 wird
dabei verdeutlicht, dass der Methode A ein Header HA und der Methode
B' ein Header HB im Stack zugeordnet ist. Über die Header
wird angezeigt, ob es sich bei dem Code der entsprechenden Methode
um einen 32-Bit-Code zur Ausführung auf der virtuellen
Maschine 41 oder um einen 16-Bit-Code zur Ausführung
auf der virtuellen Maschine 42 handelt. Auf diese Weise
kann ein einheitlicher Java-Stack für beide virtuellen
Maschinen 41 und 42 auf die Chipkarte 1 eingesetzt
werden.
-
In
dem oben beschriebenen Just-in-Time-Verfahrens wird die optimierte
Methode im RAM zwischengespeichert. In einer weiteren Ausführungsform
des erfindungsgemäßen Verfahrens kann auf die
Zwischenspeicherung im RAM verzichtet werden. In diesem Fall werden
die als optimierbar ermittelten Codeelemente sofort permanent in
entsprechende 16-Bit-Codes umgesetzt und in dem nicht-flüchtigen Speicher 5 gespeichert.
Für Codeelemente, welche nicht als optimierbar eingestuft
werden, muss bei unterschiedlichen Datentypen eine Datenumsetzung auf
den Java-Stack erfolgen. Dies kann beispielsweise durch eine generische
Routine im Codelader aufgrund der Kennzeichnung der Methode als
optimiert bzw. nicht optimiert erfolgen. Ansonsten erfolgt die Codetransformation
analog wie in dem obigen, anhand von 2 beschriebenen
Verfahren, mit Ausnahme, dass keine Ausführung des Codes
vor der permanenten Speicherung im nicht-flüchtigen Speicher
erfolgt. Die Umsetzung von Code in optimierten Code kann gemäß dem
soeben beschriebenen Verfahren als Teil des Lade/Verlinken-Vorgangs
durchgeführt werden.
-
Das
erfindungsgemäße Verfahren kann auch in virtuellen
Maschinen mit einem Just-in-Time-Compiler verwendet werden, wobei
die Methoden in diesem Fall durch den Compiler in Maschinencode
umgesetzt werden.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- - WO 2005/069136
A1 [0003, 0003]
-
Zitierte Nicht-Patentliteratur
-
- - „Handbuch
der Chipkarten" von W. Rankl und W. Effing, Hanser Verlag, 4. Auflage,
2002, Seiten 308 bis 328 [0002]