JavaCard Speicherverwaltung

[hasso]

Hallo,

ich hab im Forum leider keinen Bereich für JavaCard gefunden, hoffe aber das sich vlt doch der ein oder andere damit auskennt. Da so eine Karte ja mehr oder minder auch ein "mobiles Gerät" ist, poste ich mal hier.

Bin seit einigen Wochen frisch in dem Thema und finde mich noch zurecht, eine JavaCard <-> JavaHost Kommunikation habe ich bereits auf die Beine gestellt. Jetzt im Moment versuche ich rauszufinden wie die Speicherverwaltung der JavaCard genau funktioniert.

Aus der Doku lese ich raus das sich auf der Karte ein ROM, RAM und EEPROM befindet. ROM ist erstmal uninteressant. Im EEPROM liegen persistente Daten, also alle Objekte die für immer und ewig auf der Karte bleiben (ausser man löscht das Applet). Im RAM alles temporäre was nach einem Reset (ziehen der Karte aus dem Terminal) wieder weg ist.

Da die JavaCard keine GarbageCollection besitzt muss man sich C-Style um seine Objekte selbst kümmern. Dynamisches anlegen von Objekten mittels "new" zur Laufzeit führt damit zwangsläufig zu memory leaks, da diese immer in den EEPROM geschrieben werden. D.h. alle Objekte die gebraucht werden müssen einmalig im Konstruktor angelegt werden der beim installieren des Applets einmalig vom JCRE aufgerufen wird.

Nur was ist jetzt mit lokalen Variablen ? Wenn ich innerhalb einer Methode eine Variable anlege, meinetwegen:

short bytesRead = apdu.setIncomingAndReceive();

Liegt "bytesRead" dann im RAM ? Sind die nach verlassen der Methode weg ? Oder erst nach ziehen der Karte ? Oder nie ? Legt der mir da jedesmal einen neuen short in den Speicher ? Muss ich dann wirklich jede einzelne Variable die irgendwo auf der Karte benutze global vorher anlegen und initialisieren ?

Kann dazu einfach keine Informationen finden...vlt kennt sich hier ja jemand aus.

Viele Grüße

 

[Ullenboom]

Lokale Variablen leben auf dem Stack, also einer ganz besonderen Sektion des Hauptspeichers (RAM). Nach dem Verlassen der Methode wird der Stack-Speicher für andere lokale Variablen benutzt.

 

[schlingel]

Das stimmt so aber nur für primitive Datentypen. Objekte leben auf einem Heap.

 

[hasso]

Hallo,

es geht mir in diesem Fall nur um lokale, primitve Datentypen, um genau zu sein um short und byte, Objekte darf ich lokal sowieso keine erzeugen.
Da die JVM auf der Karte quasi "für immer" läuft und der Speicher sehr begrenzt ist ist das Ganze irgendwie knifflig. Erzeugte Objekte an die ich nichtmehr rankomme (weil lokal erzeugt und Methode verlassen) sind für immer verloren und mit ihnen der Speicher, da es keine GC gibt.

Ich weiß jetzt nur eben nicht ob dies auch für primitive Datentypen gilt und ich die alle (wie die Objekte und Arrays auch) global anlegen muss, einmal im Konstruktor und dann immer wiederverwenden muss.

Grüße

 

[schlingel]

Dezidiert ist da schwer etwas zu garantieren. Ich hab auch nichts dazu gefunden wie JavaCard den LifeCycle managed. Normalerweise ist es so wie Ullenboom schreibt. Hast du schon versucht Oracle bzgl. deiner Frage anzuschreiben?

 

[hasso]

Nein, bisher noch nicht.
Werde es morgen mal im Oracle Forum versuchen.

In Dokumentationen und im Netz wird immer nur von "erzeugten Objekten" geredet, die auf keinen Fall zur Laufzeit erzeugt werden dürfen sondern nur einmalig am Anfang und dann immer wiederverwertet müssen. Nur von den primitven Datentypen schreibt niemand.

 

[hasso]

Hallo,

so die Lösung nach Oracle, nur falls es jemanden interessiert.
Lokale Variablen primitver Datentypen werden wie erwartet auf den Stack gelegt und auch wieder gelöscht, wird die Methode beendet. Alles was mittels "new" erzeugt wird aber nicht, das liegt direkt im EEPROM und darf daher nur einmal im Konstruktor erzeugt werden.

Da der Stack auf der Karte aber recht klein ist muss man darauf achten nicht zuviele lokale Variablen zu erstellen, sondern eher immer dieselben wieder zu verwerten. Aufgrund dessen ist auch eine zu tiefe Verschachtelung von Methoden zu vermeiden, am sinnvollsten nur 2-3Stufen tief.

Viele Grüße