Dynamische Adaption in heterogenen verteilten eingebetteten ...

5.4 Eine JVM als Baukasten
müssen. Ob die Anwendung dynamisches Laden von Klassen einsetzt, kann durch Analyse des Codes
festgestellt werden.
Da eine laufende Anwendung im Normalfall selten zusätzliche Klassen benötigt, bietet sich das
Auslagern des Klassenladers an. Lediglich zur Startzeit werden viele Klassen neu in die VM geladen.
Aber auch hier kann ein externer Klassenlader sinnvoll sein. Speziell dann, wenn die Klassendaten
nicht lokal vorliegen, sondern erst zum Knoten übertragen werden müssen. Durch externes Ausführen
des Klassenladers entfällt das Laden und Analysieren der Klassendaten vor Ort. Stattdessen können
direkt die vorbereiteten Datenstrukturen zum Gerät übertragen werden.
Ist die Laufzeitumgebung aus optimierten Bausteinen aufgebaut, so muss der Verwalter ohnehin
darüber informiert werden, dass dem System neuer Code und neue Typen hinzugefügt werden. Der
Verwalter kann dann die Voraussetzungen der optimierten Bausteine überprüfen und sie gegebenenfalls
durch andere Varianten ersetzen, die unter den neuen Gegebenheiten optimal arbeiten.
5.4.7.2 Verifier
Der Verifier prüft, ob eine geladene Klasse die JVM-Spezifikation [LY99] erfüllt. Dabei wird zum
Beispiel geprüft, ob alle Befehle gültig sind und ob das Ziel eines Sprungbefehls der Anfang und nicht
die Mitte eines anderen Befehls ist. Neben vielen weiteren Überprüfungen ist besonders die Typprüfung
wichtig. Dabei wird festgestellt, dass für jede Operation der Typ der Daten zu der darauf angewandten
Operation passt.
Abbildung 5.15: Abhängigkeiten des Verifiers
Der Verifier wird vom Klassenlader nach dem Laden der binären Klassendefinition aufgerufen. Erst
wenn die Klasse erfolgreich überprüft wurde, fährt der Klassenlader mit dem Installieren der Klasse
fort.
Der Verifier ist hauptsächlich von den konstanten Klassendaten abhängig. Er kann daher gut als
externer Dienst angeboten und separat vor dem Laden aktiviert werden. Das Auslagern des Verifiers
zusammen mit dem Klassenlader ist besonders sinnvoll, da dann die gesamte Vorverarbeitung am
Verwalter durchgeführt werden kann.
5.4.7.3 Binder
Beim Binden werden die symbolischen Referenzen innerhalb einer Klassendefinition aufgelöst. Symbolische
Referenzen sind zum Beispiel Referenzen auf Typen bei der Definition von Feldern oder
der Name von Methoden bei Methodenaufrufen. Werden während des Bindens Klassen oder Typen
referenziert, die noch nicht geladen sind, so wird der Klassenlader beauftragt, diese Klassen zu laden.
119