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.4 E<strong>in</strong>e JVM als Baukasten<br />

wieder freizugeben. Sie ist nicht für den Inhalt des Speichers verantwortlich und entscheidet somit<br />

auch nicht selbstständig, wann e<strong>in</strong> Speicherbereich wieder als frei gilt. Benötigt e<strong>in</strong> Dienst e<strong>in</strong>en zuvor<br />

angeforderten Speicherbereich nicht mehr, so meldet er das an die Speicherverwaltung, welche den<br />

Speicherbereich dann als verfügbar kennzeichnet. E<strong>in</strong>e Besonderheit stellt die Objektverwaltung dar,<br />

da die Speicherverwaltung hier e<strong>in</strong>e Speicherbere<strong>in</strong>igung <strong>in</strong>itiieren kann, um unbenutzten Speicher<br />

zu f<strong>in</strong>den. Schlägt e<strong>in</strong>e Speicheranforderung fehl, da nicht genügend Speicher frei ist, so erfolgt e<strong>in</strong>e<br />

Kommunikation mit der Ausnahmebearbeitung, welche den Fehler an den Aufrufer weiterleitet.<br />

Abbildung 5.5: Abhängigkeiten der Speicherverwaltung<br />

Die Speicherverwaltung ist e<strong>in</strong> <strong>in</strong>terner Dienst, der nicht direkt von e<strong>in</strong>er Anwendung aufgerufen<br />

wird, sondern nur durch andere Dienste, welche Speicher benötigen. So wird die Objektverwaltung<br />

Speicher anfordern, sobald sie e<strong>in</strong> neues Objekt anlegen will; die Klassenverwaltung benötigt Speicher,<br />

wenn e<strong>in</strong>e neue Klasse geladen werden soll und die Threadverwaltung wird beim Erzeugen e<strong>in</strong>es neuen<br />

Threads Speicher belegen, um den Stack und die Verwaltungsstruktur des neuen Threads abzulegen.<br />

Von der Nutzung dieser drei Dienste hängt es demnach ab, ob die Speicherverwaltung ausgelagert<br />

werden soll. Die Objekterzeugung hat dabei den größten E<strong>in</strong>fluss auf die Entscheidung. Da es <strong>in</strong> Java<br />

nicht vorgesehen ist, Objekte auf dem Stack e<strong>in</strong>er Methode zu erzeugen, müssen alle Objekte auf dem<br />

Heap erzeugt werden. Hierzu ruft die Objektverwaltung jedes Mal die Speicherverwaltung auf und ist<br />

somit der stärkste Nutzer.<br />

Man kann den Speicherbereich nach dem Verwendungszweck <strong>in</strong> zwei Bereiche e<strong>in</strong>teilen:<br />

1. Speicher für Klassendaten und Verwaltungsstrukturen. Diese Daten werden selten gelöscht und<br />

unterliegen nicht der Speicherbere<strong>in</strong>igung, sondern werden explizit freigegeben.<br />

2. Speicher, der durch Objekte belegt wird. Er wird häufiger wieder freigegeben.<br />

Da Klassen- und Verwaltungsdaten weniger dynamisch s<strong>in</strong>d, ist die Auslagerung dieser Speicherverwaltung<br />

leichter zu entscheiden.<br />

S<strong>in</strong>d die möglichen Objekttypen bekannt, so kann, zur Optimierung, die Granularität der Speicherverwaltung<br />

an die möglichen Objektgrößen angepasst werden. Je nach Verfahren kann dadurch das<br />

Suchen von freien Speicherblöcken beschleunigt werden.<br />

5.4.3 Objektverwaltung<br />

Die Objektverwaltung ist zuständig für das Anlegen und Initialisieren neuer Objekte. Sie bestimmt<br />

außerdem das Objektlayout, das heißt die Struktur e<strong>in</strong>es Objekts im Speicher. Auch das Entfernen<br />

von nicht mehr benötigten Objekten ist Aufgabe der Objektverwaltung. Entsprechend der Aufgaben<br />

kann man die Objektverwaltung <strong>in</strong> drei Komponenten aufteilen: die Objektlayoutverwaltung, die<br />

Objekterzeugung und die Speicherbere<strong>in</strong>igung.<br />

109

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!