kapitel 3 implementierung kapitel 3. implementierung ... · bei eintritt in den block wird...

Vorlesung „Objektorientierte Softwareentwicklung“Sommersemester 2010So e se este 0 0

Kapitel 3 Implementierung Kapitel 3. Implementierung objektorientierter Sprachen

MotivationSpeicherbereiche

Umsetzung von KlassendeklarationengObjekterzeugung

Nachrichten und dynamisches Binden

ProzedurausführungProzedurausführung

Motivation

Basiskonzepte besser verstehen! Dadurch besser verstehen warum bestimmte Dadurch besser verstehen, warum bestimmte

Programmiertechniken wichtig sind!

Th Themen Was „statisch“ und „dynamisch“ praktisch bedeutet „Dynamisches Binden“ ist keine Magie und auch nicht

ineffizient! Warum man Objekte erzeugen, aber nicht „zerstören“

kann Warum man Variablen, die auf nicht mehr benötigte

Objekte zeigen null zuweisen sollte!

Prof. Dr. A. Weber, Dr. G. Kniesel Vorlesung „OOSE – Objektorientierte Softwareentwicklung“, Sommersemester 2010 3-2

Warum Objekterzeugung teuer ist!

Speicherbereiche

Statischer Bereich für Klassen und Interfaces Speicher für Klassenvariablen – daher static Speicher für Klassenvariablen daher static Code von Klassenmethoden C d I t th d Code von Instanzmethoden Sprungtabelle zu Instanzmethoden (für dyn. binding)

Dynamischer Bereich für Objeke (Halde / heap) Heap-Verwaltung incl. “Garbage Collection“p g g Dynamisches Binden von Nachrichten

Dynamischer Bereich für Aufrufe (Stapel / stack) Dynamischer Bereich für Aufrufe (Stapel / stack) Stackframes für Aufrufparameter


Stackverwaltung

Objekterzeugung und Objekterzeugung und Speicherverwaltung

Verwaltung von Objekten im Speicher

Der Stapelspeicher wird gemäß der Bl k k d P i hBlockstruktur des Programms automatisch verwaltet Jeder Aufruf hat ein „Stackframe“ Stackframe = Speicher für alle Aufrufparameter

In Java liegen Objekte grundsätzlich auf dem Haldenspeicher (Heap) Sie sind über Referenzvariablen zugänglich, die auf

dem Stapel liegen und deren Referenzen auf die Halde zeigenHalde zeigen

Das Java-Laufzeitsystem organisiert die Halde mittels einer automatischen Speicherverwaltung


mittels einer automatischen Speicherverwaltung


Der Ausdruck new K(); reserviert den S i h l t fü i Obj kt d KlSpeicherplatz für ein Objekt der Klasse K Außerdem wird das Objekt initialisiert

Der Ausdruck new K() liefert eine Referenz auf das neue geschaffene Objekt


Verwaltung von Objekten im Speicher: BeispielBeispiel Beispiel: Wir betrachten

die Speicherbilder beim Stack: Heap:die Speicherbilder beim Ausführen folgender Codesequenz: irgendwas

Stack: p

q

{

noch was

Time t;t = new Time();

}}




Stack: p

q

{

noch was

t = nullTime t;t = new Time();

}}

Bei Eintritt in den Block wird zunächst Platz für die lokalen Variablen (hier: Time t) auf dem Stack geschaffen und mit Null vorinitialisiertdem Stack geschaffen und mit Null vorinitialisiert


Verwaltung von Objekten im Speicher: BeispielBeispiel

Beispiel: Wir Stack: Heap:

::Time0

betrachten die Speicherbilder beim Ausführen folgender

irgendwas

Stack: p

sec = 0min = 0hrs = 0

Ausführen folgender Codesequenz:{

noch was

t = null{ hrs 0Time t;t = new Time();

}


}}

Danach legt new ein neues Objekt vom Typ Time mit auf default-Werte vorinitialisierten Membervariablen auf dem Heap an

}


Verwaltung von Objekten im Speicher: BeispielBeispiel

Beispiel: Wir Stack: Heap:

::Time0

betrachten die Speicherbilder beim Ausführen folgender

irgendwas

Stack: p


Ausführen folgender Codesequenz:{

noch was

t{ hrs 0Time t;t = new Time();

}


}}

Als nächstes bekommt die Variable t eine Referenz auf das neu erzeugte Objekt zugewiesen

}




Stack: p

::Time0

q

{

noch was

{



}


}

hrs 0

}

Zum Abschluss wird der Block verlassen, wodurch die Referenz auf das Objekt verloren geht.D Obj k i b “

}

Das Objekt „stirbt“


Verwaltung von Objekten im Speicher: ErreichbarkeitErreichbarkeit

Objekte auf der Halde leben (unabhängig von der

Stack:(unabhängig von der Blockstruktur des Programms) so lange, wie sie über R f i bl i hb

...

i Obj k

M Obj

Referenzvariable erreichbar (reachable) sind

Ein Objekt ist indirekt

meinObjekt

Heap:::MyObjectwert=1234

next

Ein Objekt ist indirekt erreichbar, wenn es über eine Referenzvariable

::MyObjectwert=0 next

erreichbar ist, die als Feld in einem anderen erreichbaren Objekt

wert 0next

erreichbaren Objekt vorkommt– Das Objekt, das den Wert 0

enthält ist direkt erreichbar

::MyObjectwert=42next=null


enthält ist direkt erreichbar, die weiteren Objekte sind indirekt erreichbar

next=null


Tote Objekte auf der Halde bezeichnet man als Abfall (garbage)

Um den Haldenspeicher wieder verwenden zu Um den Haldenspeicher wieder verwenden zu können, kennt das Java-Laufzeitsystem eine automatische Speicherbereinigung oderautomatische Speicherbereinigung oder „Abfallsammlung“ (garbage collection) Die es z B anstößt wenn der Haldenspeicher zur Die es z.B. anstößt, wenn der Haldenspeicher zur

Neige geht


C++: Explizite Verwaltung von Objekten im Speicherim Speicher In C++ hingegen muss (bzw. darf) die

Speicherrückgabe explizit programmiert werdenSpeicherrückgabe explizit programmiert werden Der Programmierer muss für jede von ihm

entworfene Klasse eine spezielle Funktionentworfene Klasse eine spezielle Funktion schreiben, einen sogenannten Destruktor (destructor), in der die Rückgabe des Speichers ( ), g pvon einem nicht mehr benötigten Objekt beschrieben wird

f O f Dieser ruft i.A. einen Operator delete auf Dies ist in vielen Fällen effizienter als eine

automatische Speicherbereinigungautomatische Speicherbereinigung Ist aber für den Programmierer sehr viel

umständlicher und kann leicht zu Programmierfehlern


umständlicher und kann leicht zu Programmierfehlern führen

C++: Explizite Verwaltung von Objekten im Speicherim Speicher

Insbesondere können dabei in C++ (nicht in Java) folgende Programmierfehler vorkommen:

Immer mehr Speicher wird verbraucht„Speicherleck“ (memory

Speicher für ein Objekt wird irrtümlicherweise nicht zurückgegeben

leak)

nicht zurückgegeben, obwohl es tot ist

Speicher für ein Objekt i d fäl hli h i

Solche Fehler sind extrem boshaft da sie erst dannwird fälschlicherweise

zurückgegeben wird, obwohl es noch nicht totist

boshaft, da sie erst dann bemerkt werden, wenn der Speicherplatz erneut zugeteilt und überschriebenist zugeteilt und überschriebenwurde


Verwaltung von Objekten im Speicher: Garbage CollectionGarbage Collection Ein einfaches Prinzip der automatischen

Speicherbereinigung besteht aus zwei Phasen:Speicherbereinigung besteht aus zwei Phasen: markieren (mark) und (zusammen )kehren (sweep) (zusammen-)kehren (sweep)

In der Markierungsphase geht man von unten nach oben über den Stack und markiert rekursiv alle von denüber den Stack und markiert rekursiv alle von den Referenzvariablen aus erreichbaren Objekte auf dem Heap

In der Kehrphase kehrt man allen nicht markierten Speicher auf dem Heap in eine Freispeicherliste (freelist) zusammen und löscht die Markierungenlist) zusammen und löscht die Markierungen Man kann sogar die markierten Objekte in eine Ecke der Halde

kehren (verschieben), denn der Java-Programmierer bekommt


die tatsächlichen Werte der Referenzen nie zu Gesicht

Verwaltung von Objekten im Speicher: Garbage CollectionGarbage Collection Es gibt noch andere Prinzipien der Speicherbereinigung

E i t i J i ht f t h i b l h b t t d Es ist in Java nicht festgeschrieben, welche benutzt werden Mit komplizierteren Methoden kann z. B. erreicht werden,

dass Objekte, die oftmals in kurzen Abständendass Objekte, die oftmals in kurzen Abständen hintereinander benutzt werden (z. B. in einer Schleife), nach einer Speicherbereinigung in benachbarte Stellen im Speicher zu liegen kommenSpeicher zu liegen kommen Alle modernen Prozessoren sind mit einem Cache-Speicher

(cache memory) ausgestattet, auf den sehr viel schneller als auf den Hauptspeicher zugegriffen werden kannden Hauptspeicher zugegriffen werden kann– Dieser hat eine beschränkte Größe, es können aber

zusammenhängende Stücke vom Hauptspeicher sehr schnell zu ihm transferiert werden

– Somit kann evtl. die Ablaufgeschwindigkeit eines Programms erheblich gesteigert werden, wenn bei der Speicherbereinigung verkettete Objekte in benachbarte Bereiche im Heap gelegt werden

Weiteres mögliches Problem beim Garbage Collection:


Weiteres mögliches Problem beim Garbage Collection: Echtzeitanwendungen

Dynamisches Binden bei „überladenen“ und

„überschriebenen“ Methoden

Folgende Beispielszenarien:

1. Gleiche Nachrichtensignatur / Empfängerobjekte verschiedener Klassen

2. Verschiedene Nachrichtensignaturen / Gleiches Empfängerobjekt

Umsetzen von dynamischem Binden Folgendes Szenario setzen wir auf den nächsten Folien um Es geht Folgendes Szenario setzen wir auf den nächsten Folien um. Es geht

immer um die Umsetzung des Aufrufs von „berechneKosten()“:

Mi b i XYZMitarbeiter

l di A ft ()

...

XYZ

doSth()

...

erledigeAuftrag()berechneKosten()

berechneKosten()

doSth()UML

m:MitarbeiterberechneKosten()

:XYZ

class Mitarbeiter {erledigeAuftrag() {...}berechneKosten(){...}

class XYZ {doSth() {

Mitarbeiter m; (){ }}

;...; m.berechneKosten();

}

Java


}

Überblick

Zuerst: Allgemeine Grundlagen Dynamisches Binden in rein objektbasierten (d.h.

nicht klassenbasierten) und nicht streng getypten Sprachen

Objekte mit Methodentabellenverweisen

Anschliessend: Java, C++, Eiffel, und Co Anpassung an klassenbasierte strang typisierte Anpassung an klassenbasierte, strang typisierte

Sprachen

Abschluss: Anwendung in versch Szenarien Abschluss: Anwendung in versch. Szenarien Überladen versus Überschreiben


Zusammenspiel mit Vererbung

Methodentabellen (rein objektbasiert) Szenario (Ursprünglicher Code in fiktiver Objektsprache): Szenario (Ursprünglicher Code in fiktiver Objektsprache):

object Mitarbeiter = {erledigeAuftrag() {...}b h K t (){ }

object XYZ {doSth(m) {

b h K t ()berechneKosten(){...}}

m.berechneKosten(); }

}

Umsetzung der Objektdefinitionen Jedes Objekt verweist auf seine Methodentabelle! Jeder Eintrag in einer Methodentabelle verweist auf den übersetzten Code

einer Methode!

vtable ( = virtual method table)

Speicherbereich des erledigeAuftrag

Mitarbeiter::erledigeAuftrag()Speicherbereich für

V i bl

Speicherbereich des referenzierten Objektes

Übersetzte

... berechneKosten


Mitarbeiter::erledigeAuftrag()Mitarbeiter::berechneKosten()

Variable m (enthält eine ObjektID)

Übersetzte Methoden

Nachrichten (rein objektbasiert) Szenario (Ursprünglicher Code in fiktiver Objektsprache): Szenario (Ursprünglicher Code in fiktiver Objektsprache):

object Mitarbeiter = {erledigeAuftrag() {...}b h K t (){ }

object XYZ {doSth(m) {

b h K t ()berechneKosten(){...}}

m.berechneKosten(); }

}

Umsetzung von Nachrichten Jede Nachricht wird durch ein Stück Code ersetzt, das anhand der

Methodentabelle des Empfänger Objektes den auszuführendenMethodentabelle des Empfänger-Objektes den auszuführenden Methodencode bestimmt.

m.berechneKosten(..) m.vtable.getValue(berechneKosten)(..);

vtable ( = virtual method table)

Speicherbereich des erledigeAuftrag

Mitarbeiter::erledigeAuftrag()Speicherbereich für

V i bl

Speicherbereich des referenzierten Objektes

Übersetzte

... berechneKosten


Mitarbeiter::erledigeAuftrag()Mitarbeiter::berechneKosten()

Variable m (enthält eine ObjektID)


Prozeduraufrufe versus Nachrichten

object.berechneKosten(...);

C, Pascal & Co C++, Java & Co

berechneKosten(obj,param1, ..., paramN);;

... // Parameterübergabe ... // Parameterübergabe jump addresseXXXXX; addresse =

object.vTable.getValue(berechneKosten);jump addresse;

addresseXXXXX: ... // Code von „berechneKosten“return;

addresseXXXXX: ... // Code von „berechneKosten“return;

Nachricht ≠ Prozeduraufruf

return; ;

Die Adresse des auszuführenden Codes ist an der Aufrufstelle nicht bekannt!

Auch in verteilten Umgebungen einsetzbar!


Eine Nachricht Verschiedene Effekte, je nach Empfänger!

Methodentabellen (Klassenbasiert, streng typisiert)

Besonderheiten klassenbasierter Sprachen Klasse definiert gemeinsame Methoden für alle Instanzen

– Klasse hat Methodentabelle die für alle Instanzen gilt – Objekte verweisen auf ihre Klasse und diese verweist auf die

Methodentabelle Menge der Methoden und Felder einer Klasse ändern sich nicht zur Menge der Methoden und Felder einer Klasse ändern sich nicht zur

Laufzeit– Methodennamen als explizite Schlüssel für jede Referenz auf

Methodencode sind nicht mehr erforderlich– Stattdessen kann der Compiler jeder Methode einen festen Index in

der Methodentabelle einer bestimmten Klasse vergeben– Beispiel: indexOf(Mitarbeiter, berechneKosten) = 2

Ref. auf Code von erledigeAuftrag()Ref auf Code von berechneKosten()

12

...vtable ( = virtual method table)

classSpeicherbereich der

Speicherbereich der Klasse „Mitarbeiter“

Ref. auf Code von berechneKosten()2

Mitarbeiter::erledigeAuftrag()

...

Speicherbereich für Variable m

referenzierten Instanz von „Mitarbeiter“



Mitarbeiter::berechneKosten()(enthält eine ObjektID) Methoden

Methodentabellen (Klassenbasiert, streng typisiert)

S i (U ü li h J C d ) Szenario (Ursprünglicher Java-Code):class Mitarbeiter {

erledigeAuftrag() {...}berechneKosten(){ }


Mitarbeiter m;berechneKosten(){...}}

Mitarbeiter m; ...; m.berechneKosten(); } }

Schema der Umsetzung der Klassendefinitionen Jedes Objekt verweist auf seine Klasse! Jede Klasse verweist auf ihre Methodentabelle! Jede Klasse verweist auf ihre Methodentabelle! Jeder Eintrag in der Methodentabelle verweist auf den übersetzten Code

einer Methode!


12






...






Nachrichten (Klassenbasiert, streng typisiert)

Szenario (Ursprünglicher Java Code): Szenario (Ursprünglicher Java-Code):class Mitarbeiter {

erledigeAuftrag() {...}berechneKosten(){ }


Mitarbeiter m;berechneKosten(){...}}

Mitarbeiter m; ...; m.berechneKosten(); } }

Umsetzung von Nachrichten: Schema Umsetzung von Nachrichten: Schema obj.msg(..) obj.class.vtable[indexOf(obj.class,msg)] (..); Dank statischer Indexermittlung zu jeder Methode kann für indexOf(....) schon beim

Compilieren eine feste Konstante eingesetzt werden

Umsetzung von Nachrichten: Beispiel m.berechneKosten(..) m.class.vtable[2](..);


12






...






Dynamisches Binden: Effizienz

Der Zugriff obj.class.vtable[index](..) reduziert die Kosten von dynamischem Binden aufvon dynamischem Binden auf 2 lesende Speicherzugriffe (obj.class.vtable[index]) und ... 1 Sprung an die in der Methodentabelle gefundene Adresse 1 Sprung an die in der Methodentabelle gefundene Adresse Davon ist der Sprung an eine nicht vorhersehbare Adresse am teuersten!

– Er bedeutet, dass die in der Anweisungspipeline des Prozessors schon im voraus geladenen Instruktionen nicht wirklich die sind, die man als nächstes braucht. Statt sofort weiterarbeiten zu können muss der Prozessor erst mal warten bis die von der Sprungadresse geholten Instruktionen bei ihm eintreffenProzessor erst mal warten, bis die von der Sprungadresse geholten Instruktionen bei ihm eintreffen.

Auch dafür gibt es weitere Optimierungen die aber den Rahmen der Vorlesung sprengen Inlining Polymorphic inline caches (Urs Hölze) Just in time“ Compilierung (Urs Hölzle) „Just-in-time Compilierung (Urs Hölzle) Dynamische „HotSpot“ Recompilierung (Urs Hölzle) http://www.cs.ucsb.edu/~urs/oocsb/papers.shtml


Dynamic Binding und Overriding

class Super {

void m(String s) {...}class Client { ( g ) { }}Super obj;

obj = new Super(...);obj.m("bla");

overridingobj = new Sub(...);obj.m("bla");

}

obj.class.vtable[2]("bla");

class Sub extends Super {void m(String s) {...}

}

Gleiche Signatur gleicher Methodentabellen-Index

Methodentabelle der Unterklasse verweist auf der gleichen Indexposition auf die eigene Methode


gleichen Indexposition auf die eigene Methode

Dynamic Binding und Vererbung

class Super {

void m(String s) {...}class Client { ( g ) { }}Super obj;


geerbtobj = new Sub(...);obj.m("bla");

}

obj.class.vtable[2]("bla"); geerbt von


}

Gleiche Signatur gleicher Methodentabellen-Index

Methodentabelle der Unterklasse verweist auf der gleichen Indexposition auf die geerbte Methode


gleichen Indexposition auf die geerbte Methode

Overriding versus Overloading: Szenario 1

class Super {void m(String s, int i) {...}void m(String s) {...}

Szenario 1

class Client { ( g ) { }}Super obj;



}


O idi


}

Overriding Beziehung zwischen Methoden in Oberklasse und Unterklasse Gl i h Si t l i h O ti Gleiche Signatur gleiche Operation

– bekommen gleichen Methodentabellen-Index Die spezifischste Methode (= Implementierung der Operation) gilt!


p ( p g p ) g Methodentabelle der Unterklasse verweist auf Indexposition 2 auf die eigene Methode statt die

Überschriebene



Szenario 1




}


Unter der Lupeclass Sub extends Super {

void m(String s) {...}}

Der Empfänger „obj“ hat in beiden Nachrichten den statischen Typ „Super“ ... m(„bla“) hat die Aufrufsignatur m(String) ... die spezifischte Obersignatur von m(String) in Super ist m(String) ... der Index von m(String) ist 2 Also wird beide male der gleiche Code generiert:



Der dynamische Typ des Empfängers ist in der ersten Nachricht „Super“ und in der zweiten Nachricht „Sub“.



Szenario 2


obj = new Super(...);obj.m("bla", 10);

overloadingbj l t bl [2]("bl ")

obj.m("bla");} obj.class.vtable[1]("bla", 10);


O l di


}

Overloading Beziehung zwischen Methoden innerhalb einer Klasse M th d h b l i h N b hi d Si t Si Methoden haben gleichen Namen aber verschiedene Signatur Sie

stellen verschiedene Operationen dar– sie bekommen verschiedene Methodentabellen-Indices


OOP: Overriding versus Overloading (Szenario 2)


(Szenario 2)


obj = new Super(...);obj.m("bla", 10);

bj l t bl [2]("bl ")overloading

obj.m("bla");}


obj.class.vtable[1]("bla", 10);

U t d L


}

Unter der Lupe Hausaufgabe (5 Minuten): Lesen Sie sich die vorangegangenen Folien

dieses Abschnitts noch einmal aufmerksam durchdieses Abschnitts noch einmal aufmerksam durch. Hausaufgabe (2 Minuten): Versuchen Sie nach vorherigem Schema

(Seite 3-29) die Erklärung selbst zu rekonstruieren


OOP: Overriding versus Overloading (Szenario 2b)


(Szenario 2b)


obj = new Sub(...);obj.m("bla", 10);

obj.class.vtable[1]("bla", 10);

obj.m("bla");}

overridingobj.class.vtable[2]("bla");

O idi d O l di


}

Overriding und Overloading zusammen Gleiche Signatur in Oberklasse und Unterklasse Gl i h O ti l i h I d i M th d t b ll Gleiche Operation gleicher Index in Methodentabellen Die spezifischste Methode (= Implementierung der Operation) gilt!

Methodentabelle der Unterklasse verweist auf Indexposition 2 auf die eigene Methode statt die Ü


Überschriebene

OOP: Overriding versus Overloading (Szenario 2b)


(Szenario 2b)


obj = new Sub(...);obj.m("bla", 10);

obj.class.vtable[1]("bla", 10);overriding

obj.m("bla");}


U t d L


}

Unter der Lupe Hausaufgabe (3 Minuten): Versuchen Sie nach vorherigem Schema die

Erklärung selbst zu rekonstruierenErklärung selbst zu rekonstruieren


Fazit

„Dynamisches Binden“ ist nicht teuer Durch die statisch indizierten Methodentabellen sehr effizient!

Fehlende „Destruktoren“ Objekte können nicht explizit „zerstört“ werden um die

Konsistenz des Speichers zu gewährleistenKonsistenz des Speichers zu gewährleisten

Erreichbarkeit ist Kriterium für „lebendige“ Objekte Variablen die auf nicht mehr benötigte Objekte zeigen sollte Variablen, die auf nicht mehr benötigte Objekte zeigen sollte

man null zuweisen, um dem „garbage Collector die Erkennung von „Müll“ zu ermöglichen!

Objekterzeugung ist teuer Aufwand automatischer Speicherverwaltung Programmiertechnik zur Vermeidung überflüssiger

Objekterzeugenung– Objektpools Wiederverwendung von Objekten


– StringBuffer (veränderlich) statt String (unveränderlich, immer wieder neu erzeugt "a" +"b" erzeugt neuen String "ab" statt die Parameter zu verketten!)

kapitel 3 implementierung kapitel 3. implementierung ... · bei eintritt in den block wird...

Documents