Virtual Machine Support for Aspect-Oriented Programming Languages

240 Pages·2006·2.8 MB·English

Virtual Machine Support
for Aspect-Oriented Programming Languages
Vom Fachbereich Informatik
der Technischen Universita¨t 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. Mira Mezini
Korreferent: Prof. dr. Theo D’Hondt, Vrije Universiteit Brussel
Tag der Einreichung: 27. Oktober 2005
Tag der mu¨ndlichen Pru¨fung: 16. Dezember 2005
Darmstadt
D17

Abstract
Aspect-oriented programming (AOP) is, like structured, logic, functional or object-
oriented programming, a programming paradigm in its own right. Each paradigm offers
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
system is possible. This becomes evident, for example, when parts of the functionality
of a concern that logically belong together are scattered over several modules of the
system and appear to be tangled with these modules’ codes. Such concerns that cannot
be cleanly modularised are called crosscutting concerns.
While the aforementioned problems are metinmost ofthe paradigms when a complex
systemisdecomposedtoitsmodules,AOPregardstheproblematiccrosscuttingconcerns
as modules of their own and introduces a new module concept, called aspects.
Apart from state and functionality, an aspect also bundles a description of its cross-
cutting behaviour. To that end, it describes at which points in the execution of an
application its own functionality must be called. These points are called join points.
Situations that lead to the occurrence of join points and hence to the invocation of
aspect functionality are described using pointcuts. A pointcut quantifies over the set
of all join points and selects from the set, aided by certain designators, those at which
the invocation of aspect functionality is desired. Aspect functionality is represented in
so-called advice 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. The locations in application code where advice invocations are woven in are
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, it cannot be determined at weave-time for all join point shadows
whether join points will indeed occur at them when the application is running. Hence,
conditionals are woven in addition at some shadows that decide, based on run-time
state, whether advice are to be invoked. These conditionals are called residues. In this
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. Weaving at run-time has the advantage that, e.g., in the context of J2EE
applications, objects can be dynamically and transparently decorated with certain ser-
vices that are important in J2EE applications. Moreover, dynamic weaving makes more
allowancefortheinherentlydynamicnatureofpointcutsthanstaticweaving—pointcuts
quantify over the execution of an application.
The different approaches to dynamic weaving however lack the kind of support for
1
AOP language mechanisms that is common for mechanisms of other paradigms: direct
support from the run-time environment. For example, virtual machines for object-
oriented programming languages offer direct support for resolving virtual methods via
method tables. Such support is at present not available for aspect-oriented mechanisms.
Instead, the implementation of a run-time environment for AOP languages is simulated
at application level.
This is where this work applies. In the course of this work, Steamloom was imple-
mented, a virtual machine with explicit support for AOP mechanisms. Steamloom is an
extension of an existing virtual machine for the Java programming language.
Steamloom provides a unified representation of Java bytecodes that is accessed by
both the virtual machine and the AOP functionality. The latter utilises the bytecode
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.
Apartfromthat, SteamloomhasintegratedsupportforsomeotherAOPmechanisms, 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-
mented experimentally. The pointcut model and weaver are extensible, which allows
for the implementation of new elements. This extensibility was used in this work to
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. It is based on a presentation of implementation details of these AOP imple-
mentations that has been achieved on the basis of a unified presentation framework.
2
Zusammenfassung
Die aspektorientierte Programmierung (AOP) ist, ebenso wie die strukturierte, logi-
sche, funktionale oder objektorientierte Programmierung, ein eigensta¨ndiges Program-
mierparadigma. Jedes Paradigma bietet seinen Anwendern bestimmte Mo¨glichkeiten,
Anwendungsdoma¨nen in Module zu dekomponieren.
Die Dekomposition komplexer Systeme st¨oßt bei den vier Letztegenannten regelma¨ßig
auf das Problem, dass keine eindeutige Modularisierung bestimmter Belange des Sys-
tems m¨oglich ist. Dies a¨ußert sich beispielsweise darin, dass Teilfunktionalita¨ten eines
Belangs, die logisch zusammenh¨angen, u¨ber mehrere Module des Systems zerstreut sind
und in diesen Modulen als Einsprengsel im Quelltext auftauchen. Solche nicht sauber
modularisierbaren Belange werden als crosscutting concerns bezeichnet.
Wa¨hrend 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 fu¨hrt ein neues
Modulkonzept, die so genannten Aspekte, ein.
Ein Aspekt bu¨ndelt, zusa¨tzlich zu Daten und Funktionalita¨t, auch eine Beschreibung
seinesquerschneidendenVerhaltens. ZudiesemZweckbeschreibter,anwelchenPunkten
w¨ahrend der Ausfu¨hrung einer Anwendung die ihm eigene Funktionalita¨t aufzurufen ist.
Diese Punkte werden join points genannt.
Die Beschreibung der Situationen, die zum Auftreten von join points und somit zur
Ausfu¨hrung von Aspektfunktionalita¨t fu¨hren, geschieht mittels pointcuts. Ein pointcut
quantifiziert u¨ber die Menge aller join points und selektiert aus ihr mit Hilfe bestimmter
Bezeichner diejenigen, an denen der Aufruf von Aspektfunktionen gewu¨nscht ist. As-
pektfunktionalita¨tliegtinFormsogenannteradvice vor,welchedieFormvonProzeduren
oder Methoden haben.
Damit die solcherart mit Aspekten modularisierten crosscutting concerns in einer An-
wendung zum Einsatz kommen ko¨nnen, werden sie mit Hilfe spezieller U¨bersetzer, so
genannter ,,Weber“, in die Anwendung ,,eingewoben“. Die Stellen im Anwendungsquell-
text, an denen Aufrufe von advice eingewoben werden, heißen join point-Schatten. Ein
U¨bersetzer fu¨r eine AOP-Sprache besteht neben den bei einem U¨bersetzen u¨blichen
Teilen auch aus einem Modul zur Auswertung von pointcuts und einem Weber.
Das Modul zur pointcut-Auswertung findet die von dem pointcut beschriebenen join
point-Schatten und u¨bergibt sie an den Weber, der das Einweben von Aspektfunktio-
nalita¨t durchfu¨hrt. Jedoch steht zur Webezeit nicht fu¨r alle Schatten zweifelsfrei fest,
ob an ihnen zur Ausfu¨hrungszeit tatsa¨chlich join points auftreten. Daher werden an
manchen Schatten zusa¨tzlich Konditionale eingewoben, die, abha¨ngig vom Laufzeitzu-
stand, daru¨ber entscheiden, ob advice auszufu¨hren sind. Diese Konditionale werden
residues genannt. Von besonderem Interesse sind hierbei dynamische pointcuts, die vom
Kontrollfluss der Anwendung abha¨ngen: join points treten hierbei unter Umsta¨nden nur
im Kontext der Ausfu¨hrung einer bestimmten Methode auf.
UnterdenverschiedenenImplementierungenvonAOPhabensichaucheinigeAnsa¨tze
entwickelt, in welchen das Weben nicht notwendig zur U¨bersetzungszeit, sondern zur
Laufzeit einer Anwendung geschieht. Ein Weben zur Laufzeit bietet den Vorteil, dass,
3
beispielsweise im Kontext von J2EE-Anwendungen, Objekte dynamisch und transpar-
ent mit bestimmten Diensten ausgestattet werden k¨onnen, die im Rahmen einer J2EE-
UmgebungvongroßerWichtigkeitsind. Weiterhintra¨gtdynamischesWebenderinha¨rent
dynamischen Natur von pointcuts – sie quantifizieren u¨ber die Ausfu¨hrung einer Anwen-
dung – eher Rechnung als ein statischer Ansatz.
DieunterschiedlichenbestehendenAnsa¨tzezumdynamischenWebenlassenjedochdie
Art von Unterstu¨tzung for AOP-Sprachmechanismen vermissen, die fu¨r Sprachmecha-
nismen anderer Paradigmen gang und ga¨be ist: eine direkte Unterstu¨tzung durch die
Laufzeitumgebung. Beispielsweise bieten virtuelle Maschinen fu¨r objektorientierte Pro-
grammiersprachen direkte Unterstu¨tzung fu¨r die Auflo¨sung virtueller Methoden mittels
Methodentabellen. Eine solche Unterstu¨tzung ist fu¨r aspektorientierte Mechanismen
derzeit nicht verfu¨gbar. Statt dessen wird auf Anwendungsebene die Implementierung
einer Laufzeitumgebung fu¨r AOP-Sprachen simuliert.
An dieser Stelle setzt die vorliegende Arbeit an. Im Rahmen der Arbeit wurde Steam-
loom implementiert, eine virtuelle Maschine mit expliziter Unterstu¨tzung fu¨r AOP-
Mechanismen. Steamloom ist eine Erweiterung einer bestehenden virtuellen Maschine
fu¨r die Programmiersprache Java.
Steamloom bietet eine einheitliche Darstellungsschicht von Java-Bytecodes, auf die
sowohldie virtuelleMaschineselbstalsauchdieAOP-Funktionalita¨tzugreifen. Letztere
nutzt die Mo¨glichkeiten der Bytecode-Darstellung sowohl zur Auswertung von pointcuts
als auch zum Weben.
Desweiteren unterstu¨tzt Steamloom dynamisches Weben, indem die in der virtuellen
Maschine vorhandenen Laufzeitu¨bersetzer fu¨r Java-Bytecodes dazu benutzt werden, von
Webevorga¨ngen betroffene Methoden dynamisch neu zu u¨bersetzen. Daru¨ber hinaus
bietet Steamloom integrierte Unterstu¨tzung fu¨r einige andere Mechanismen von AOP-
Sprachen an, von denen eine effiziente Auswertung bestimmter kontrollflussabha¨ngiger
residues besonders hervorzuheben ist.
Steamloom ist als Plattform konzipiert, auf deren Basis AOP-Sprachen experimentell
implementiert werden ko¨nnen. Sowohl das pointcut-Modell als auch der Weber sind
erweiterbar, was die Implementierung neuer Elemente erlaubt. Diese Erweiterbarkeit
wurde im Rahmen dieser Arbeit genutzt, um drei verschiedene Ans¨atze fu¨r kontrollfluss-
abha¨ngige pointcuts zu implementieren und experimentell zu evaluieren.
Um den Wert von Steamloom zu ermessen, wurde eine umfassende Analyse ver-
schiedenster Aspekte der Geschwindigkeit und Effizienz einer repr¨asentativen Menge
bestehender AOP-Implementierungen durchgefu¨hrt. Sie basiert auf einer Beschreibung
von Implementierungsdetails dieser Implementierungen, die auf der Basis eines ein-
heitlichen Rahmens durchgefu¨hrt wurde.
4
Contents
1. Introduction 15
2. AOP Implementations 23
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1. Approaches to Analyse and Classify AOP Systems . . . . . . . . . 23
2.1.2. Presentation Framework . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.3. Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2. AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3. CaesarJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4. Arachne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.5. JAsCo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.6. AspectWerkz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.7. PROSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.8. Spring AOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.9. Reflex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.10.AspectS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3. Steamloom: A Virtual Machine with Aspect Support 93
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.2. Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.3. The Jikes Research Virtual Machine . . . . . . . . . . . . . . . . . . . . . 96
3.3.1. Overall Architecture and Build Process . . . . . . . . . . . . . . . 96
3.3.2. Classes, Methods and Objects . . . . . . . . . . . . . . . . . . . . . 97
3.3.3. Method Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.3.4. Adaptive Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.3.5. Run-Time Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 101
3.3.6. Magic Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.3.7. Memory Management and Garbage Collection . . . . . . . . . . . 102
3.4. Architectural Overview of Steamloom . . . . . . . . . . . . . . . . . . . . 103
3.5. Steamloom’s Programming Model . . . . . . . . . . . . . . . . . . . . . . 105
3.6. The Steamloom Aspect Model . . . . . . . . . . . . . . . . . . . . . . . . 108
3.6.1. Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.6.2. Pointcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.6.3. Join Point Shadows . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.6.4. Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5
Contents
3.7. Bytecode Management in Steamloom . . . . . . . . . . . . . . . . . . . . . 117
3.7.1. BAT: Bytecode Augmentation Toolkit . . . . . . . . . . . . . . . . 117
3.7.2. Integration of BAT into Jikes . . . . . . . . . . . . . . . . . . . . . 118
3.8. Dynamic Aspect Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.8.1. Pointcut Splitting . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
3.8.2. Join Point Shadow Retrieval . . . . . . . . . . . . . . . . . . . . . 123
3.8.3. The Steamloom Weaver . . . . . . . . . . . . . . . . . . . . . . . . 125
3.8.4. The Shape of Woven Code . . . . . . . . . . . . . . . . . . . . . . 127
3.8.5. Weaving Before and After Advice . . . . . . . . . . . . . . . . . . . 128
3.8.6. Weaving Around Advice . . . . . . . . . . . . . . . . . . . . . . . . 129
3.8.7. Join Point Context Access and Residues . . . . . . . . . . . . . . . 132
3.8.8. How Woven Code Takes Effect . . . . . . . . . . . . . . . . . . . . 135
3.9. Advice Instance Management . . . . . . . . . . . . . . . . . . . . . . . . . 137
3.9.1. The Structure of Advice Instance Tables . . . . . . . . . . . . . . . 138
3.9.2. Compiling Advice Instance Lookups . . . . . . . . . . . . . . . . . 139
3.10.Scoped Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.10.1. Instance-Local Aspects. . . . . . . . . . . . . . . . . . . . . . . . . 141
3.10.2. Thread-Local Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.11.Support for cflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
3.11.1. Approaches to Implementing cflow . . . . . . . . . . . . . . . . . 144
3.11.2. Support for cflow in Steamloom . . . . . . . . . . . . . . . . . . . 145
4. Evaluation 151
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.1.1. Technical Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.1.2. Performance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . 152
4.1.3. Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
4.2. Performance Criteria Assessment . . . . . . . . . . . . . . . . . . . . . . . 153
4.2.1. Measurement Environment . . . . . . . . . . . . . . . . . . . . . . 156
4.2.2. Overhead Measurements . . . . . . . . . . . . . . . . . . . . . . . . 156
4.2.3. Core AOP Mechanism Performance . . . . . . . . . . . . . . . . . 161
4.2.4. Footprint of Deactivated Aspects . . . . . . . . . . . . . . . . . . . 170
4.2.5. Performance of Scoped Aspects . . . . . . . . . . . . . . . . . . . . 172
4.2.6. Performance of cflow . . . . . . . . . . . . . . . . . . . . . . . . . 176
4.2.7. Weaving Performance . . . . . . . . . . . . . . . . . . . . . . . . . 186
4.2.8. Memory Consumption . . . . . . . . . . . . . . . . . . . . . . . . . 189
4.3. Technical Criteria Assessment . . . . . . . . . . . . . . . . . . . . . . . . . 194
4.3.1. Representational Overhead . . . . . . . . . . . . . . . . . . . . . . 195
4.3.2. Infrastructural Code . . . . . . . . . . . . . . . . . . . . . . . . . . 197
4.3.3. Java Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
4.4. Integrating AOP Support with the Underlying Execution Environment . . 206
6
Contents
5. Concluding Remarks and Future Work 209
5.1. Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
5.2. Limitations of the Current Implementation . . . . . . . . . . . . . . . . . 210
5.3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
A. Micro-Measurement Results 217
Bibliography 227
7
Contents
8