Figure 2 - uploaded by Michael Haupt
Content may be subject to copyright.
![9.: Concepts of Reflex (adapted from [149]).](profile/Michael-Haupt-2/publication/200040365/figure/fig4/AS:669492296306699@1536630810420/Concepts-of-Reflex-adapted-from-149.png)
Source publication
![Figure 2.9.: Concepts of Reflex (adapted from [149]).](profile/Michael-Haupt-2/publication/200040365/figure/fig4/AS:669492296306699@1536630810420/Concepts-of-Reflex-adapted-from-149_Q320.jpg)
Similar publications
Aspect-oriented programming languages usually are extensions of object-oriented
ones, and their compilation target is usually the (virtual) machine
model of the language they extend. While that model elegantly supports
core object-oriented languagemechanisms such as virtual method dispatch,
it provides no direct support for core aspect-oriented lan...
Citations
... Approaches like Javassist [7, 6] and BCEL [8] allow to apply some unanticipated changes, but only to program parts that have not been executed yet. In contrast, Steamloom [19], Reflex [44], PROSE [31], DUSC [36], AspectWerkz [3], Wool [41], or JAsCo [46] allow unanticipated changes even of executed program parts; however, Steamloom, Reflex, PROSE, AspectWerkz, Wool, and JAsCo do not support class schema changing runtime updates. Although DUSC allows ...
Software is changed frequently during its life cycle. New requirements come, and bugs must be fixed. To update an application, it usually must be stopped, patched, and restarted. This causes time periods of unavailability, which is always a problem for highly available applications. Even for the development of complex applications, restarts to test new program parts can be time consuming and annoying. Thus, we aim at dynamic software updates to update programs at runtime. There is a large body of research on dynamic software updates, but so far, existing approaches have shortcomings either in terms of flexibility or performance. In addition, some of them depend on specific runtime environments and dictate the program's architecture. We present JavAdaptor, the first runtime update approach based on Java that (a) offers flexible dynamic software updates, (b) is platform independent, (c) introduces only minimal performance overhead, and (d) does not dictate the program architecture. JavAdaptor combines schema changing class replacements by class renaming and caller updates with Java HotSwap using containers and proxies. It runs on top of all major standard Java virtual machines. We evaluate our approach's applicability and performance in non-trivial case studies and compare it with existing dynamic software update approaches. Copyright (C) 2012 John Wiley & Sons, Ltd.
... While this concern is understandable, it is clearly the responsibility of the AOP implementation to provide the required performance characteristics. It has been shown that the employment of AOP techniques does not have to have a negative impact on performance at all [24]. Also, our pragmatic adoption of AOP ideas explicitly deals with efficiency concerns in the core of the VM implementation. ...
Virtual machine (VM) implementations are made of intricately intertwined subsystems, interacting largely through implicit dependencies. As the degree of crosscutting present in VMs is very high, VM implementations exhibit significant internal complexity. This study proposes an architecture approach for VMs that regards a VM as a composite of service modules coordinated through explicit bidirectional interfaces. Aspect-oriented programming techniques are used to establish these interfaces, to coordinate module interaction, and to declaratively express concrete VM architectures. A VM architecture description language is presented in a case study, illustrating the application of the proposed architectural principles.
... The architecture of an AOP kernel hence consists of three layers (Fig. 1 ): a transformation layer in charge of basic weaving, supporting both structural and behavioral modifications of the base program ; a composition layer, for detection and resolution of aspect interactions; a language layer, for modular definition of aspect languages . It has to be noted that the transformation layer is not necessarily implemented by a (byte)code transformation system: it can very well be integrated directly in the language interpreter [14]. As a matter of fact, the role of a versatile AOP kernel is to complement traditional processors of object-oriented languages. ...
... It is true that our infrastructure is certainly not as efficient as agressively-optimized compilers like abc [1]. Nevertheless, recent performance evaluations of AOP systems [14] show that Reflex performs really well compared to other dynamic aspect systems, which makes it a reasonable platform from this point of view. Also, the conciness of language definitions and extensions makes it more suitable for rapid language prototyping and validation of ideas, because less burden is placed on the programmer than that of extending a full compiler infrastructure. ...
Domain-specific aspect languages (DSALs) bring the well-known advantages of domain specificity to the level of aspect code. However, DSALs incur the significant cost of implementing or extending a language processor or weaver. Furthermore, this weaver typically operates blindly, making detection of interactions with aspects written in other languages impossible. This raises the necessity of an appropriate infrastructure for DSALs. The case study we present here illustrates how the reflex kernel for multi-language AOP addresses these issues, by considering the implementation of a DSAL for advanced transaction management, KALA. We first detail the implementation of KALA in reflex, called relax, illustrating the ease of implementation of runtime semantics, syntax, and language translation. We then show a straightforward and modular extension to KALA at all these levels, and demonstrate how reflex helps in dealing with interactions between KALA and another DSAL for concurrency management. These invaluable assets enable faster development of DSALs as well as their ability to coexist within one application, thereby removing the most important impediments to their re-emergence in the aspect community.
... Typically, aspect-oriented programs are executed by mapping aspect-oriented constructs to Java bytecode which is then executed on a standard Java virtual machine. Recent approaches [6,7] investigate the extension of the executing Java virtual machine by aspect-oriented features. Concerning the optimization potential of these two approaches, it turns out that the first solution offers only restricted optimization gains because it is restrained entirely on the lim- ited operations of the Java bytecode. ...
... Several research has been done in the field of optimizations for AOP in general. Steamloom [6] is an extension to the Jikes Research Virtual Machine with direct support for general AOP language mechanisms. The introduced Advice Instance Tables (AIT) [7] with its efficient lookup mechanism are related to our team ac- tivation mechanism, but this work does not target embedded small applications. ...
Applications for small embedded mobile devices are becoming larger and more complex resulting in the need for advanced modularization mechanisms. Aspect-oriented modularization is a promising approach to solve this problem, but the overhead of the existing programming languages restricts their practicability for small devices with limited resources. In this paper, we identify opportunities to optimize the aspectual execution mechanism at different levels within the virtual machine. First experiments show that these optimizations improve the execution time considerably, thus proving that with adequate optimizations, we enable the use of advanced aspect-oriented modularization techniques for small device Java applications.
... One of the most important driving forces in the development of Steamloom [1,5] was high performance of woven code. Hence, not all of the join points were instrumented, like in 2nd-generation PROSE [16], nor was a debugging infrastructure used for programming purposes. ...
... The first projects that were described as general-purpose AOP kernels were Reflex [18] and Steamloom [5]. Reflex is based on behavioral reflection and performs load-time preparation of Java classes based on pre-existing specifications; at run-time, prepared join point shadows can be subject to dynamic weaving. ...
We present the implementation of several programming lan- guages with support for multi-dimensional separation of con- cerns (MDSOC) on top of a common delegation-based sub- strate, which is a prototype for a dedicated MDSOC virtual machine. The supported MDSOC language constructs range from aspects, pointcuts and advice to dynamically scoped and activated layers. The presented language implementa- tions show that the abstractions oered by the substrate are a viable target for high-level language compilers.
... In an approach that binds join points early do advice, dynamic aspect deployment is expensive since the manipulation of application bytecode and its subsequent re-installation into the execution environment are time-consuming. Approaches exhibiting fast dynamic deployment behavior by preparing join point shadows with hooks and wrappers usually suffer from the footprint of the required infrastructure [Hau06] which degrades performance of other operations. ...
... To rate the envelopes approach used in a post-compile weaver as well as a runtime weaver, the performance is measured and compared to other weaving approaches. A detailed discussion of the technology of the related approaches can be found in [Hau06]. ...
... It is future work to also implement specific code generation strategies for other LIAM entities whereby the strategies are not restricted to generating bytecode-because of the VM integration, it is also possible to directly generate machine code. Special code generation strategies will comprise the cflow optimization presented in Section 4.4, and optimized aspect instance retrieval as presented in [GDN + 08,Hau06]. ...
... We provide an overview of the functioning of the As-pectJ weaver to help understand the functionality of our coverage tool. For a complete discussion, please refer to Haupt [6] and Hilsdale [7]. AspectJ [20] is an aspectoriented extension of Java. ...
Testing aspect-oriented programs is challenging in part because of the interactions between the aspects and the base classes with which the aspects are woven. Coverage metrics, such as joinpoint coverage, address faults resulting from the changes in base class control flow that may be introduced by the woven advices. Definitions of joinpoint coverage in the literature typically require counting the execution of aspects at each joinpoint. We present a tool for measuring joinpoint coverage from two perspectives: per advice, which measures the execution of the advice at each joinpoint it is woven into, and per class, which measures the execution of all the advices in each joinpoint in the class. This gives a more detailed measurement of joinpoint coverage and helps in identifying what more needs to be tested in both the base class and the aspect. The tool is based on AspectJ and Java bytecode, and thus, does not require any source code. We demonstrate the use of our tool to measure the joinpoint coverage of test inputs generated by Xie and Zhao's Aspectra framework.
... Sec. 3.1 (10)) and initialized to null there. Semantics of new (cf. ...
... At program start, no layers are active yet, so the heap should initially be prepared in the same way as (10) for j in Sec. 3.1. ...
... Implementation-wise, a number of projects are concerned with virtual machine support for aspect-orientation [19,20,11,10,22]. Among these, PROSE 2 [20] is the only one to adopt, like our machine model, a view on the running application that explicitly regards all points in the execution as potential join points by default. ...
We describe semantic mappings of four high-level programming languages to our delegation-based machine model for aspect-oriented programming. One of the languages is a class-based object-oriented one. The other three represent extensions thereof that support various approaches to modularizing crosscutting concerns. We explain informally that an operational semantics expressed in terms of the model's concepts preserves the behavior of a program written in one of the high-level languages. We hence argue our model to be semantically sound in that sense, as well as sufficiently expressive in order to correctly support features such as class-based object-oriented programming, the open-classes and pointcut-and-advice flavors of aspect-oriented programming, and dynamic layers. For the latter, being a core feature of context-oriented programming, we also provide a formal semantics.
... The aforementioned semantic gap has been observed earlier [9] and led to the development of dedicated virtual-machine level support for AOP in the form of the Steamloom VM [9,34,33]. While Steamloom set out to bridge the gap, it has achieved less. ...
... While Steamloom set out to bridge the gap, it has achieved less. On the one hand, several techniques dedicated to offer explicit support for core AOP mechanisms have been devised [33,10,7]. On the other hand, Steamloom operates at bytecode level, still expressing AOP mechanisms targeting an object-oriented machine model. Recent advances in virtual machinelevel weaving support [7] still follow this direction. ...
... Other AOP implementations like CaesarJ [3,17], JAsCo [67,66], Association Aspects [60], Steamloom [33,34,9], PROSE [56,57,52,58] or EOS [59] also allow for deploying an aspect, e. g., only in certain threads or for certain objects. As a result, the current thread can be a dimension of dispatch, as well as the active or receiver objects themselves-not only their types. ...
Aspect-oriented programming languages usually are extensions of object-oriented
ones, and their compilation target is usually the (virtual) machine
model of the language they extend. While that model elegantly supports
core object-oriented languagemechanisms such as virtual method dispatch,
it provides no direct support for core aspect-oriented language mechanisms
suchas advice application. Hence, current implementations of aspect-oriented
languages bring about insufficient and inelegantsolutions. This paper
introduces a lightweight, object-based machine model for aspect-oriented
languages based on object-orientedones. It is centered around delegation
and relies on a very dynamic notion of join points as loci of late-bound
dispatch offunctionality. The model is shown to naturally support
an important number of aspect-oriented language mechanisms. Additionally,a
formal semantics is presented as an extension to the object-based
δ calculus.
... Dynamic weaving is a weaving process in AOP that allows the system to redefine aspects at runtime. Current implementations of dynamic weaving are, for example, PROSE [18] and Steamloom [10,9]; both are AOP systems for the Java virtual machine (JVM) execution environment. There are several models for describing the behaviour of dynamic weaving [4]. ...
This position paper proposes the use of an event-based dynamic AOP machine as an infrastructure for interactive development of high performance scientic software. Advice codes in the proposed approach are similar to mobile agents that execute on distributed computational nodes. The key ideas underlying this approach are multi-level separation of parallelisation concerns and event-driven dynamic join points. The primary aim of the research is to use the AOP paradigm to improve productivity for scientic software development; the dynamic AOP machine is also expected to be further developed as an interactive computational grid.
