Virtual machine support for aspect-oriented programming languages [Elektronische Ressource] / von Michael Haupt

Sujets

• Informatik

Informations

• Publié par: technischen_universitat_darmstadt
• Publié le: 01 janvier 2006
• Nombre de lectures: 19
• Langue: English
• Poids de l'ouvrage: 2 Mo

Extrait

Virtual Machine Support
for Aspect-Oriented Programming Languages
Vom Fachbereich Informatik
der Technischen Universit¨ at Darmstadt
zur Erlangung des akademischen Grades eines
Doktor-Ingenieurs (Dr.-Ing.)
genehmigte
Dissertation
von
Diplom-Ingenieur
Michael Haupt
geboren in Olpe
Referentin: Prof.Dr.-Ing.MiraMezini
Korreferent: Prof.dr.TheoD’Hondt,VrijeUniversiteitBrussel
TagderEinreichung: 27.Oktober2005
Tag der mundlic¨ hen Prufung:¨ 16.Dezember2005
Darmstadt
D17Abstract
Aspect-oriented programming (AOP) is, like structured, logic, functional or object-
orientedprogramming,aprogrammingparadigminitsownright.Eachparadigmoffers
its users certain possibilities to decompose application domains to modules.
The decomposition of complex systems, when adopting the four latter paradigms,
frequently leads to the problem that no clear modularisation of certain concerns of the
systemispossible.Thisbecomesevident,forexample,whenpartsofthefunctionality
of a concern that logically belong together are scattered over several modules of the
systemandappeartobetangledwiththesemodules’codes.Suchconcernsthatcannot
be cleanly modularised are calledcrosscuttingconcerns.
While the aforementioned problems are met in most of the paradigms when a complex
system is decomposed to its modules, AOP regards the problematic crosscutting concerns
as modules of their own and introduces a new module concept, calledaspects.
Apart from state and functionality, an aspect also bundles a description of its cross-
cuttingbehaviour.Tothatend,itdescribesatwhichpointsintheexecutionofan
applicationitsownfunctionalitymustbecalled.Thesepointsarecalled joinpoints.
Situations that lead to the occurrence of join points and hence to the invocation of
aspect functionality are described usingpointcuts.Apointcutquantifiesovertheset
of all join points and selects from the set, aided by certain designators, those at which
theinvocationofaspectfunctionalityisdesired.Aspectfunctionalityisrepresentedin
so-calledadvice that have the form of procedures or methods.
To let the crosscutting concerns, thus modularised using aspects, take effect in an
application, they are “woven into” the application code using special compilers called
weavers.Thelocationsinapplicationcodewhereadviceinvocationsarewoveninare
calledjoinpointshadows.AcompilerforanAOPlanguageconsists,apartfromtheusual
compiler building blocks, also of a module for evaluating pointcuts, and of a weaver.
The pointcut evaluation module retrieves the join point shadows described by the
pointcut and passes them on to the weaver, which weaves aspect functionality into the
application.However,itcannotbedeterminedatweave-timeforalljoinpointshadows
whetherjoinpointswillindeedoccuratthemwhentheapplicationisrunning.Hence,
conditionals are woven in addition at some shadows that decide, based on run-time
state,whetheradvicearetobeinvoked.Theseconditionalsarecalled residues.Inthis
respect, dynamic pointcuts that depend on the control flow of the application are of
special interest: join points may occur only in the context of the execution of a certain
method.
Among the different AOP implementations, some approaches have been developed in
which weaving does not necessarily occur at compile-time, but at run-time of an ap-
plication.Weavingatrun-timehastheadvantagethat,e.g.,inthecontextofJ2EE
applications, objects can be dynamically and transparently decorated with certain ser-
vicesthatareimportantinJ2EEapplications.Moreover,dynamicweavingmakesmore
allowance for the inherently dynamic nature of pointcuts than static weaving—pointcuts
quantify over theexecution of an application.
The different approaches to dynamic weaving however lack the kind of support for
1AOP language mechanisms that is common for mechanisms of other paradigms: direct
supportfromtherun-timeenvironment.Forexample,virtualmachinesforobject-
oriented programming languages offer direct support for resolving virtual methods via
methodtables.Suchsupportisatpresentnotavailableforaspect-orientedmechanisms.
Instead, the implementation of a run-time environment for AOP languages is simulated
at application level.
Thisiswherethisworkapplies.Inthecourseofthiswork, Steamloom was imple-
mented,avirtualmachinewithexplicitsupportforAOPmechanisms.Steamloomisan
extension of an existing virtual machine for the Java programming language.
Steamloom provides a unified representation of Java bytecodes that is accessed by
boththevirtualmachineandtheAOPfunctionality.Thelatterutilisesthebytecode
representation’s capabilities to evaluate pointcuts and for weaving.
Moreover, Steamloom supports dynamic weaving by utilising the just-in-time com-
pilers of the virtual machine for dynamically recompiling methods affected by weaving.
Apart from that, Steamloom has integrated support for some other AOP mechanisms, of
which an efficient evaluation of control flow-dependent residues is especially important.
Steamloom is conceived as a platform on whose basis AOP languages can be imple-
mentedexperimentally.Thepointcutmodelandweaverareextensible,whichallows
fortheimplementationofnewelements.Thisextensibilitywasusedinthisworkto
implement and evaluate three different strategies for control flow-dependent pointcuts.
To measure the value of Steamloom, a comprehensive analysis of different aspects of
performance and efficiency of a representative collection of AOP implementations was
conducted.ItisbasedonapresentationofimplementationdetailsoftheseAOPimple-
mentations that has been achieved on the basis of a unified presentation framework.
2Zusammenfassung
Die aspektorientierte Programmierung (AOP) ist, ebenso wie die strukturierte, logi-
sche, funktionale oder objektorientierte Programmierung, ein eigenst¨ andiges Program-
mierparadigma.JedesParadigmabietetseinenAnwendernbestimmteM¨ oglichkeiten,
Anwendungsdom¨ anen in Module zu dekomponieren.
Die Dekomposition komplexer Systeme st¨ oßt bei den vier Letztegenannten regelm¨ aßig
auf das Problem, dass keine eindeutige Modularisierung bestimmter Belange des Sys-
tems m¨oglichist.Dies¨außert sich beispielsweise darin, dass Teilfunktionalit¨ aten eines
Belangs, die logisch zusammenh¨ angen, ub¨ er mehrere Module des Systems zerstreut sind
undindiesenModulenalsEinsprengselimQuelltextauftauchen.Solchenichtsauber
modularisierbaren Belange werden alscrosscuttingconcerns bezeichnet.
W¨ ahrend sich in den meisten Paradigmen die genannten Probleme bei der Dekom-
position eines komplexen Systems in seine Module ergeben, fasst die AOP die prob-
lematischen crosscutting concerns als eigenst¨ andige Module auf und fuhrt¨ ein neues
Modulkonzept, die so genanntenAspekte,ein.
Ein Aspekt bundelt,¨ zus¨ atzlich zu Daten und Funktionalit¨ at, auch eine Beschreibung
seinesquerschneidendenVerhaltens.ZudiesemZweckbeschreibter,anwelchenPunkten
w¨ ahrend der Ausfuhrung¨ einer Anwendung die ihm eigene Funktionalit¨ at aufzurufen ist.
Diese Punkte werdenjoinpoints genannt.
Die Beschreibung der Situationen, die zum Auftreten vonjoinpoints und somit zur
Ausfuhrung¨ von Aspektfunktionalit¨ at fuhren,¨ geschieht mittelspointcuts.Ein pointcut
quantifiziert ub¨ er die Menge allerjoinpoints und selektiert aus ihr mit Hilfe bestimmter
Bezeichner diejenigen, an denen der Aufruf von Aspektfunktionen gewunsc¨ htist.As-
pektfunktionalit¨ at liegt in Form so genannteradvice vor, welche die Form von Prozeduren
oder Methoden haben.
Damit die solcherart mit Aspekten modularisiertencrosscuttingconcerns in einer An-
¨wendung zum Einsatz kommen konnen,¨ werden sie mit Hilfe spezieller Ubersetzer, so
genannter,,Weber“,indieAnwendung,,eingewoben“.DieStellenimAnwendungsquell-
text, an denen Aufrufe vonadvice eingewoben werden, heißenjoinpoint-Schatten.Ein
¨ ¨Ubersetzer fur¨ eine AOP-Sprache besteht neben den bei einem Ubersetzen ublic¨ hen
Teilen auch aus einem Modul zur Auswertung vonpointcuts und einem Weber.
Das Modul zurpointcut-Auswertung findet die von dempointcut beschriebenenjoin
point-Schatten und ub¨ ergibt sie an den Weber, der das Einweben von Aspektfunktio-
nalit¨ at durchfuhrt.Jedo¨ chstehtzurWebezeitnichtf¨ur alle Schatten zweifelsfrei fest,
ob an ihnen zur Ausfuhrungszeit¨ tats¨ achlichjoin points auftreten.Daherwerdenan
manchen Schatten zus¨ atzlich Konditionale eingewoben, die, abh¨ angig vom Laufzeitzu-
stand, darub¨ er entscheiden, ob advice auszufuhren¨ sind.DieseKonditionalewerden
residues genannt.VonbesonderemInteressesindhierbeidynamische pointcuts,dievom
Kontrollfluss der Anwendung abh¨ angen:joinpoints treten hierbei unter Umst¨ anden nur
im Kontext der Ausfuhrung¨ einer bestimmten Methode auf.
Unter den verschiedenen Implementierungen von AOP haben sich auch einige Ans¨ atze
¨entwickelt, in welchen das Weben nicht notwendig zur Ubersetzungszeit, sondern zur
LaufzeiteinerAnwendunggeschieht.EinWebenzurLaufzeitbietetdenVorteil,dass,
3beispielsweise im Kontext von J2EE-Anwendungen, Objekte dynamisch und transpar-
ent mit bestimmten Diensten ausgestattet werden k¨onnen, die im Rahmen einer J2EE-
UmgebungvongroßerWichtigkeitsind.Weiterhintr¨agt dynamisches Weben der inh¨ arent