14.01.2015 Aufrufe

Dynamische Adaption in heterogenen verteilten eingebetteten ...

Dynamische Adaption in heterogenen verteilten eingebetteten ...

Dynamische Adaption in heterogenen verteilten eingebetteten ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

5 Kontroll- und Verwaltungsschicht<br />

Abbildung 5.16: Abhängigkeiten des B<strong>in</strong>ders<br />

Das Auflösen e<strong>in</strong>er Referenz muss vor deren Nutzung durchgeführt werden. Der B<strong>in</strong>der kann<br />

daher direkt nach dem Laden e<strong>in</strong>er Klasse durch den Klassenlader aufgerufen werden oder erst zur<br />

Ausführungszeit von der Ausführungse<strong>in</strong>heit. Um Bauste<strong>in</strong>e auszulagern, ist es jedoch s<strong>in</strong>nvoll, den<br />

Wirkungsbereich e<strong>in</strong>es Bauste<strong>in</strong>s auf wenige def<strong>in</strong>ierte Zeiträume e<strong>in</strong>zuschränken. Daher eignet sich<br />

für dieses Ziel e<strong>in</strong> vollständiges B<strong>in</strong>den zum Ladezeitpunkt am besten. Der Code kann dann vom<br />

Verwalter vorbereitet und gebunden werden, bevor er zum Gerät übertragen wird.<br />

Dieses Vorgehen kann sowohl beim Starten der Anwendung als auch beim Nachladen von Klassen<br />

angewandt werden. Besonders s<strong>in</strong>nvoll ist diese Lösung, wenn gleichzeitig der Klassenlader und der<br />

Verifier ausgelagert werden.<br />

5.4.7.4 Compiler<br />

Abbildung 5.17: Abhängigkeiten des Compilers<br />

Soll der Bytecode direkt von der Zielplattform verarbeitet werden, so wird zusätzlich zur Ausführungse<strong>in</strong>heit<br />

e<strong>in</strong> Compiler benötigt, der den Bytecode <strong>in</strong> Masch<strong>in</strong>encode übersetzt. Je nach dem<br />

Zeitpunkt des Übersetzens unterscheidet man beim Kompilieren zwischen zwei verschiedenen Ansätzen.<br />

Wird der Bytecode erst <strong>in</strong> Masch<strong>in</strong>encode übersetzt sobald er benötigt wird, so spricht man von<br />

e<strong>in</strong>em Just-In-Time Compiler (JIT-Compiler); wird der Code zu e<strong>in</strong>em früheren Zeitpunkt übersetzt, so<br />

spricht man von e<strong>in</strong>er Ahead-Of-Time Übersetzung (AOT-Compiler).<br />

Das erste Verfahren kann e<strong>in</strong>en Java-Bytecode Interpreter ergänzen oder vollständig ersetzen. Meist<br />

ist dabei e<strong>in</strong> Zwischenspeicher vorgesehen, der kompilierte Methoden oder Teile davon vorhält, bis sie<br />

wieder benötigt werden, um den Compiler nicht bei jedem Aufruf e<strong>in</strong>er Methode erneut aufrufen zu<br />

müssen.<br />

Bei der Ahead-Of-Time Übersetzung wird die gesamte Anwendung <strong>in</strong> Masch<strong>in</strong>encode übersetzt,<br />

unabhängig davon, ob jede e<strong>in</strong>zelne Methode auch aufgerufen wird. Dies stellt zwar möglicherweise<br />

unnötigen Übersetzungsaufwand dar, dafür wird der Übersetzungsvorgang meist vor dem Starten<br />

der Anwendung durchgeführt, wodurch zur Laufzeit ke<strong>in</strong>e Übersetzung mehr stattf<strong>in</strong>den muss. Das<br />

dynamische Nachladen von Klassen zur Laufzeit ist mit diesem Ansatz jedoch nicht ohne Weiteres<br />

möglich. Meist wird hierzu zusätzlich e<strong>in</strong> Interpreter oder e<strong>in</strong> JIT-Compiler e<strong>in</strong>gesetzt.<br />

Der Compiler eignet sich gut, als externer Dienst ausgelagert zu werden. Er arbeitet nur auf den<br />

Klassendaten und hat sonst ke<strong>in</strong>e Abhängigkeiten zu anderen Diensten. Der Kompilierungsdienst erhält<br />

dann den Java-Bytecode und liefert die übersetzte Version zurück. Bei Systemen, die zur Laufzeit<br />

kompilieren, wird häufig das Ziel verfolgt, die Ausführung der Anwendung durch Kompilieren des<br />

120

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!