Chapter 1 Overview
6.3 Intermediate Languages and Execution En- En-vironmentsEn-vironments
Recently, the potential of providing optimizations for aspect-oriented lan-guage constructs in the virtual machine has also been addressed by other projects. Currently, there are two projects related to the work presented in this thesis with a reasonable VM integration.
Intermediate Languages and Execution Environments
6.3.1 Nu
The Nu project [DR08, RDNH06] aims at providing an interface between compilers and execution environments, just like the FIAL framework devel-oped in this thesis. For this purpose, two new instructions are added to the intermediate language of the base language—in Nu, as in this thesis, this is Java. The new instructions arebind andremove which correspond to deploy-ing respectively undeploydeploy-ing pointcut-and-advice. The pointcut-and-advice definitions themselves are realized as a composition of Java objects, like in this thesis. When bind is executed, it expects apattern object and adelegate object on the operand stack. The pattern argument corresponds to the point-cut part, however, Nu’s model is restricted to patterns that can be statically evaluated, i.e., fully evaluate to join point shadows. The delegate argument refers to a method that implements the advice functionality. Executing the bind instruction returns a handle that can be used to remove the binding later.
The Java HotSpot [Hot08] virtual machine, i.e., an industrial strength VM, is extended in the Nu project to execute the new intermediate instruc-tions. HotSpot has three modes of executing methods of an application: they may be interpreted, JIT compiled without optimizations and JIT compiled with optimizations. In any case, each method has a stub that is executed before the method is itself executed. The stub tests whether the method has been compiled and jumps to the compiled code in that case; otherwise, the method is interpreted. Nu applies the advice dispatch mechanism within this stub, i.e., when the stub gets executed it looks up and invokes applicable advice. Furthermore, Nu implements a caching strategy, so that the look-up does not have to be performed at every method invocation.
The aspect model of Nu is less detailed than the LIAM meta-model de-veloped in this thesis. Nu patterns cannot express conditions on dynamic properties of join points like the required type of the receiver object orcflow. But the effect of these conditions can be emulated. Binding values from the join point’s context for use by the delegate can also not be specified declar-atively in the current model of Nu.
A possible realization ofcflowwith the means of Nu is discussed in [DR08].
Consider that constituentEnter and constituentExit are patterns of join point shadows that constitute the control flow—in the Nu’s join point model, it is specified as part of the pattern if the start or the end of a join point is selected—and dependent is a pattern of join point shadows that depend on the control flow. The pattern constituentEnteris bound to a delegate that, in turn, binds dependent to the actual advice; similarly, constituentExit is bound to a delegate that removes the binding ofdependent to the advice.
Intermediate Languages and Execution Environments
While referring to dynamic properties of join points, e.g., bycflow, can be emulated in Nu, the logic is implemented in the delegates and not explicitly present in the program’s intermediate representation. In this thesis, it is argued that only such an explicit representation facilitates optimizations like the one for cflow presented in Section 4.4.
Because of the tight virtual machine integration, Nu, like the prototypes presented in Chapter 4, exhibits a very good performance. The support for dynamic deployment comes at an average cost of 1.5% overhead whereas no overhead is imposed at all by the prototype for optimized dynamic deploy-ment developed in this thesis. The performance of executing the bind and remove instructions has been measured in [DR08] by a small benchmark that binds respectively removes a delegate to one specific method. On average the required time is 11 µs for the bind operation and 3.4 µs for the remove operation. While this result is very good, it is not directly comparable to the results presented in Section 5.2 where deployment affected hundreds join point shadows at once. Furthermore, Nu’s current approach of using method stubs for advice dispatch only works in the interpreter mode of HotSpot.
6.3.2 Lightweight VM Support for AspectJ
Golbeck et al. [GDN+08] have implemented extensions to the Jikes Research Virtual Machine to provide dedicated support to programs compiled with the AspectJ compiler. Their extended virtual machine expects that the As-pectJ compiler has woven the aspects into the application code, and that the woven code is annotated with meta-information so that it can be identified.
Any Java virtual machine can simply execute the woven bytecode, thus, it supports all features of AspectJ. For some features, however, the extended VM offers special support. Woven code that represents such a feature can be identified by the meta-information and optimized machine code can be generated for it.
This is in contrast to the approach followed in this thesis; here it is ex-pected that aspects are not woven at all, but the complete weaving is per-formed by the execution environment. In order to also support features where no special optimizations are implemented, the work presented in this thesis employs a default code generation strategy.
Golbeck et al. claim that their approach may combine optimizations driven by static analyses as performed by the abc compiler with dynamic optimizations performed by the virtual machine. Such a combination is in-deed promising as complex static analyses are too expensive to be applied at runtime. However, as of this writing, this possibility is only theoretical, as the abc compiler does not generate the appropriate meta-information.
Intermediate Languages and Execution Environments
The lightweight AspectJ virtual machine has succeeded in providing min-imally invasive support for AspectJ in so far that arbitrary code compiled with the standard AspectJ compiler can be executed. Hence the compiled code does not have any dependency to the virtual machine. This is similar to the work presented in this thesis. The importer-based approach of inte-grating AO languages in Section 3.4 also facilitates to execute applications that are compiled with the standard AspectJ compiler. However, the work presented here is not tailored just towards one specific AO language, but aims at supporting multiple languages.
The VM optimizations for AO concepts presented in [GDN+08] target at retrieval of aspect instances, advice invocation, cflow and around advice execution. Thecflow optimization is a partial re-implementation of the one presented in Section 4.4. It is assumed that the other optimizations can also be realized as special code generation strategies in FIAL-based execution environments; the implementation is subject to future work.