Optimising aspectJ

Abstract

AspectJ, an aspect-oriented extension of Java, is becoming increasingly popular. However, not much work has been directed at optimising compilers for AspectJ. Optimising AOP languages provides many new and interesting challenges for compiler writers, and this paper identifies and addresses three such challenges.First, compiling around advice efficiently is particularly challenging. We provide a new code generation strategy for around advice, which (unlike previous implementations) both avoids the use of excessive inlining and the use of closures. We show it leads to more compact code, and can also improve run-time performance. Second, woven code sometimes includes run-time tests to determine whether advice should execute. One important case is the cflow pointcut which uses information about the dynamic calling context. Previous techniques for cflow were very costly in terms of both time and space. We present new techniques to minimise or eliminate the overhead of cflow using both intra- and inter-procedural analyses. Third, we have addressed the general problem of how to structure an optimising compiler so that traditional analyses can be easily adapted to the AOP setting.We have implemented all of the techniques in this paper in abc , our AspectBench Compiler for AspectJ, and we demonstrate significant speedups with empirical results. Some of our techniques have already been integrated into the production AspectJ compiler, ajc 1.2.1.

An Aspect-Oriented Communication Middleware System

“…The results of the first experiment show that the ajc compiler introduces a considerable size overhead. Certainly, the reason is that this compiler does not support many optimizations that are possible in aspect-oriented languages [2]. On the other hand, the results using the abc are much more acceptable.…”

Zero-Overhead Composable Aspects for .NET

“…In particular, the AspectJ implementations ajc [17] and abc [7] use bytecode rewriting to implement "around" advice in many cases. They still seem to incur boxing and unboxing overhead when calling Proceed on target methods with primitive return type, although the exact circumstances are not so clear [7, §3.3].…”

“…By contrast, AOP implementations for C and C++, such as AspectC++ [35], generally favour efficiency over flexibility of the aspects. Modern implementations of AspectJ avoid much of the runtime overhead too, though not all [7,17].…”

Debugging Aspect-Enabled Programs

“…Dynamic residue (if, instanceof, and cflow residue left over by dynamic crosscuts) [4,21]. Can involve runtime reflection or calls into the AOP system.…”

“…In the domain of optimizing compilers [1], the problem is caused by the removal, merging, duplication (in-lining), reordering, or interleaving of instructions. In the domain of AOP weaving, the code location problem is usually caused by the removal (e.g., hoisting [4]), insertion (e.g., code synthesis, dynamic residue, aspect method calls, aspect in-lining, closures), duplication (e.g., initialization in-lining), or reordering (e.g., due to aroundadvice) of instructions [21]. The problem causes the debugger to show the wrong source line or call stack, or show byte code (or machine code) instead of source code.…”