\chapter{Zusammenfassung und Ausblick}
\label{resumee}

Der dynamische Methodenaufruf, Schl"ussel zur Ausdrucksm"achtigkeit objektorientierter 
\mbox{Sprachen}, ist Ursache 
f"ur die schwache Ausf"uhrungsgeschwindigkeit und schwierige 
Optimierbarkeit von TooL-Programmen.
Methodenaufrufe sind langsamer als statisch \mbox{gebundene} Prozeduraufrufe,
und Optimierungen sind in der Regel vor der Laufzeit nicht
wirkungsvoll oder sogar unm"oglich.
Rein objektorientierte Sprachen
sind erheblich st"arker von \mbox{diesen} Einschr"ankungen betroffen
als hybride Sprachen mit imperativen und objektorientierten Elementen,
da in ersteren auch Kontrollstrukturen und Variablenzugriffe "uber Botschaften 
implementiert sind.
TooL ist eine rein objektorientierte Sprache, in der
Berechnungen  ausschlie\3lich "uber  dynamische Methodenaufrufe
erfolgen. Damit wird ein objektorientierter Modellierungs\-ansatz
von der Sprache vollst"andig unterst"utzt, und der Sprachkern
bleibt mit wenigen Grundkonstrukten klein. 
In dieser Arbeit wurde ein Verfahren vorgestellt, mit
dem TooL-Programme optimiert werden k"onnen.
 Die Optimierungsstrategie kann durch folgende Punkte 
zusammengefa\3t werden:
\begin{itemize}
\item
Eine Klassenanalyse  gest"utzt von Profilinformation und einem
begrenzten Satz von \mbox{markierten} Typen
wie {\sf Int, Bool, Fun, Char} und {\sf String} ersetzt dynamische Methodenaufrufe durch
statische Prozeduraufrufe.
\item
Eine erweiterte Beta-Reduktion integriert anschlie\3end kurze Methoden
an statisch \mbox{gebundenen} 
Aufruforten und "uberf"uhrt Endrekursionen in Iterationen.
\item
Ein zentraler Methodencache enth"alt optimierte Methoden und
sorgt daf"ur, da\3 \mbox{optimierte} Methoden nur f"ur zul"assige Empf"anger
aufgerufen werden.
\item
Sowohl die Profilinformation als auch der zentrale Methodencache
sind persistent. Somit kann Laufzeitinformation "uber mehrere
Sitzungen hinweg festgehalten werden, und nach einer Optimierungsphase
liegt ein optimierter
Methodencache  nach jedem Systemstart vor.
\end{itemize}

Dieses Optimierungsverfahren erzielt recht gute Performanzsteigerungen
um einen Faktor von zwei bis drei, wobei
der Codezuwachs nur bei 1,76 liegt. Die Frequenz von Methodenaufrufen
wird um den Faktor 1,6 verringert. H"olzle berichtet f"ur
den SELF-Optimierer, da\3 dieser
die Frequenz der Methodenaufrufe im Schnitt
um den Faktor 3,6 verringert \cite{Hoelzle94}.
Das schw"achere Ergebnis des TooL-Optimierers kann an einer fehlenden
Klassenabsch"atzung liegen, die  bewu\3t 
ausgelassen wurde, um eine Vergr"o\3erung des Codes durch Klassentests und
einen Codeverschiebungslauf ({\em splitting}) zu vermeiden. 

Als Alternative zur Klassenabsch"atzung bietet sich aufgrund
der Erfahrungen dieser \mbox{Arbeit} folgendes an:
Die Typinferenz des TooL-Typpr"ufers ermittelt mit Hilfe der Typ\-deklarationen 
im Quelltext die
Signaturen aller Ausdr"ucke und Bezeichner. Die Information dieser
Sig\-naturen kann  damit der TML-Generierungsphase zur Verf"ugung stehen.
In dieser Phase kann f"ur einige 
Methodenaufrufe 
eine Expansion erfolgen, wenn die Empf"angertypen zu den
markierten Typen z"ahlen. Auf diese Weise k"onnen schon vor
dem profilgesteuerten Optimierungslauf Aufrufe mit den 
Basisselektoren wie {\sf \sfrontq +,-,*\sbackq} usw. ersetzt werden,
ohne da\3 auf eine Klassenabsch"atzung zur"uckgegriffen werden mu\3.






Die M"oglichkeit, durch aufwendigere Codegenerierung f"ur eine virtuelle
Registerarchitektur  bessere Laufzeiten zu erzielen, wurde ebenfalls 
untersucht. Die virtuelle Kellermaschine TVM wurde durch eine Registermaschine
mit 16 Registern und einem Zwei-Adre\3-Format ersetzt. Die Optimierungsstrategie der Codegenerierung
ist folgenderma\3en:

\begin{itemize}
\item
Ein Registerzuordnungsverfahren ermittelt aus festgelegten Registernutzungen
von \mbox{Variablen} geeignete Definitionsregister, um Registerbewegungen
zu minimieren.
\item
W"ahrend der Codeemission werden die Vorschl"age der Registerzuordnung
von dem
Code\-generator befolgt, wenn diese keinen Lebendigkeitskonflikt
ergeben.
\end{itemize}

Das Verfahren erzeugt recht guten Code mit wenigen Redundanzen.
Allerdings l"auft dieser nicht nennenswert schneller als der 
Kellermaschinencode der TVM.
Der Hauptgrund hierf"ur ist, da\3 die Register der
virtuellen Maschine im Hauptspeicher liegen.
Ferner behindert die hohe Aufrufdichte von TooL- oder TL-Programmen die 
Effektivit"at der Registerallokation. Weiterhin ist
die Codegenerierung f"ur eine Registermaschine erheblich aufwendiger
und  damit komplexer als f"ur eine Kellermaschine, so da\3
der Einsatz einer virtuellen Registermaschine f"ur
Sprachen wie TooL oder TL nicht geeignet ist.

Aus diesen beiden Ergebnissen l"a\3t sich eine m"ogliche 
Nachfolgearchitektur des TooL-Backends gewinnen:
Ein TML-Baum, in dem schon zur "Ubersetzung Botschaften
an markierte Typen eliminiert werden, wird in einen
Kellermaschinenbytecode "ubersetzt. Dieser kann entweder
interpretiert  oder vor der Ausf"uhrung "ahnlich
wie in \cite{DeSchi84} \mbox{dynamisch} in realen Maschinencode 
"ubersetzt werden. Methoden in  Maschinencode k"onnen in
einem \mbox{Cache} gehalten und bei Bedarf "uberschrieben werden, 
wenn die Konvertierung von
Bytecode in Maschinencode schnell verl"auft. Erste Ergebnisse
mit Maschinencode, der  "uber eine C-Code-Generierung
mit Hilfe eines C-"Ubersetzers erzeugt wurde, zeigen,
da\3 durch die Elimination der TVM-Interpreterschleife 
Leistungssteigerungen um einen Faktor von zwei bis sechs m"oglich 
sind \cite{Weikard96}.
Durch eine profilgesteuerte Optimierungsphase werden weitere 
Botschaften und Endrekursionen 
eliminiert. Der optimierte Bytecode k"onnte in dieser neuen
Architektur vor der 
Ausf"uhrung ebenfalls in Maschinencode konvertiert und in
dem Cache gehalten werden.



Das Ergebnis der vorliegenden Arbeit ist, da\3  der konzeptuelle Vorteil
eines rein objekt\-orientierten Sprachentwurfs durch die Technologie
des TooL-Optimierers unterst"utzt wird. Der Anspruch der
reinen Objektorientierung  wird durch die Optimierungsmechanismen
nicht verletzt.
Damit dient TooL neben Smalltalk und SELF als weiteres Beispiel f"ur eine
\mbox{praktikable}, rein objektorientierte Sprache, die f"ur 
reale Anwendungen geeignet ist.
