Efficient runtime aspect weaving for Java applications

Abstract

ContextThe aspect-oriented paradigm is aimed at solving the code scattering and tangling problem, providing new mechanisms to support better separation of concerns. For specific scenarios where high runtime adaptability is an important requirement, dynamic Aspect-Oriented Programming (AOP) represents a useful tool. With dynamic AOP, components and aspects can be woven and unwoven at runtime, enabling applications greater responsiveness when dealing with different or changing requirements. However, this responsiveness typically incurs a cost in terms of runtime performance and memory consumption. ObjectiveBuild an efficient dynamic aspect weaver for Java that provides the best runtime performance compared to the existing approaches, minimum memory overhead consumption, and similar functionalities to the widespread runtime weavers. MethodWe design and implement weaveJ, a dynamic aspect weaver for Java. This dynamic weaver leverages the invokedynamic opcode introduced in Java 7, which allows dynamic relinkage of method and field access. We compare the functionalities of weaveJ with the existing dynamic weavers for Java, and evaluate their runtime performance and memory consumption. ResultsweaveJ shows the best runtime performance for all benchmarks and real applications executed. Method interception with invokedynamic is at least 142% faster than the techniques used by the existing runtime weavers. The average cost of dynamic weaving using invokedynamic is only 2.2% for short running programs, and 1.5% for long running applications. Moreover, the use of aspects in weaveJ does not imply additional memory consumption. ConclusionThe dynamic aspect weaver implemented demonstrates that invokedynamic is a suitable mechanism to provide efficient runtime aspect weaving for Java applications. Moreover, it supports concurrent and programmatic aspect (un)weaving at any point of execution, a wide set of join points, class and object weaving, and allow aspects to have their own state. Neither the Java language nor the virtual machine needs to be modified.