Olaf Spinczyk

A quantitative analysis of aspects in the eCos kernel

Nearly ten years after its first presentation and five years after its first application to operating systems, the suitability of Aspect-Oriented Programming (AOP) for the development of operating system kernels is still highly in dispute. While the AOP advocacy emphasizes the benefits of AOP towards better configurability and maintainability of system software, most kernel developers express a sound skepticism regarding the thereby induced runtime and memory costs: Operating system kernels have to be lean and efficient.We have analyzed the runtime and memory costs of aspects in general, on the level of μ-benchmarks, and by refactoring and extending the eCos operating system kernel using AspectC++, an AOP extension to the C++ language. Our results show that most AOP features do not induce a intrinsic overhead and that the actual overhead induced by AspectC++ is very low. We have also analyzed a test case with significant aspect-related costs. This example shows how the structure of the underlying kernel can have a negative impact on aspect implementations and how these costs can be avoided by an aspect-aware design.Based on this analysis, our conclusion is that AOP is suitable for the development of operating system kernels and other kinds of highly efficient infrastructure software.

Program instrumentation for debugging and monitoring with AspectC

Monitoring is a widely-used technique to check assumptions about the real-time behavior of a system, debug the code, or enforce the system to react if certain deadlines are passed. Program instrumentation is needed to insert monitoring code fragments into the monitored system if the monitor is implemented without hardware support. This paper describes a language-based approach to automated program instrumentation using the general purpose aspect language AspectC++. The language is an extension to the C/C++ programming language. It provides language features that allow a highly modular and thus easily configurable implementation of monitoring tasks and supports re-use of common implementations. Even though the AspectC++ language provides a convenient level of abstraction no overhead is imposed on the system in comparison to pure C/C++ code.

Generic Advice: On the Combination of AOP with Generative Programming in AspectC++

Besides object-orientation, generic types or templates and aspect- oriented programming (AOP) gain increasing popularity as they provide addi- tional dimensions of decomposition. Most modern programming languages like Ada, Eiffel, and C++ already have built-in support for templates. For Java and C# similar extensions will be available in the near future. Even though promis- ing, the combination of aspects with generic and generative programming is still a widely unexplored field. This paper presents our extensions to the As- pectC++ language, an aspect-oriented C++ derivate. By these extensions aspects can now affect generic code and exploit the potentials of generic code and tem- plate metaprogramming in their implementations. This allows aspects to inject template metaprograms transparently into the component code. A case study demonstrates that this feature enables the development of highly expressive and efficient generic aspect implementations in AspectC++. A discussion whether these concepts are applicable in the context of other aspect-oriented language extensions like AspectJ rounds up our contribution.

Approaching Non-functional Properties of Software Product Lines: Learning from Products

Approaching the configuration of non-functional properties (NFPs) in traditional software systems is not an easy task, addressing the configuration of these properties in software product lines (SPLs) imposes even further challenges. Therefore, we have devised the Feedback Approach, which extends the traditional SPL development techniques in order to improve the configuration of NFPs. In this work we present the general guidelines of our approach and also we show the feasibility of the idea by presenting a case study using the Linux Kernel.

Generative software-based memory error detection and correction for operating system data structures

Recent studies indicate that the number of system failures caused by main memory errors is much higher than expected. In contrast to the commonly used hardware-based countermeasures, for example using ECC memory, software-based fault-tolerance measures are much more flexible and can exploit application knowledge, such as the criticality of specific data structures. This paper presents a software-based memory error protection approach, which we used to harden the eCos operating system in a case study. The main benefits of our approach are the flexibility to choose from an extensible toolbox of easily pluggable error detection and correction schemes as well as its very low runtime overhead, which totals in a range of 0.09-1.7 %. The implementation is based on aspect-oriented programming and exploits the object-oriented program structure of eCos to identify well-suited code locations for the insertion of generative fault-tolerance measures.

Design rationale of the PURE object-oriented embedded operating system

The PURE project aims at providing a portable, universal runtime executive for deeply embedded parallel/distributed systems. The phrase “deeply embedded” refers to systems forced to operate under extreme resource constraints in terms of memory, CPU, and power consumption. The notion “parallel/distributed” relates to the fact that embedded systems are becoming more and more complex in terms of architectural viewpoints. This paper discusses design issues of a family-based, object-oriented operating system targeting the area of deeply embedded systems in the above-mentioned sense. It is shown that a modular system consisting of a large number of reusable abstractions can be compiled to a fairly small and compact entity.

Using AOP to develop architectural-neutral operating system components

The architecture of an operating system, e.g. micro kernel or monolithic kernel, is usually seen as something static. Even during the long lasting evolution of operating system code it is extremely hard and, thus, expensive to change the architecture. However, our experience is that architectural evolution is often required and an architecture-neutral way to develop operating system components should be found. After analyzing why architectural flexibility is so difficult to achieve, we propose Aspect-Oriented Programming (AOP) as a solution. An example from the PURE OS family, which is implemented in an aspect-oriented programming language called AspectC++, will demonstrate the usefulness of the approach, which allows to separate the code that implements architectural properties from the core functionality.

Avoiding Pitfalls in Fault-Injection Based Comparison of Program Susceptibility to Soft Errors

Since the first identification of physical causes for soft errors in memory circuits, fault injection (FI) has grown into a standard methodology to assess the fault resilience of computer systems. A variety of FI techniques trying to mimic these physical causes has been developed to measure and compare program susceptibility to soft errors. In this paper, we analyze the process of evaluating programs, which are hardened by software-based hardware fault-tolerance mechanisms, under a uniformly distributed soft-error model. We identify three pitfalls in FI result interpretation widespread in the literature, even published in renowned conference proceedings. Using a simple machine model and transient single-bit faults in memory, we find counterexamples that reveal the unfitness of common practices in the field, and substantiate our findings with real-world examples. In particular, we demonstrate that the fault coverage metric must be abolished for comparing programs. Instead, we propose to use extrapolated absolute failure counts as a valid comparison metric.

Aspects in hardware: what do they look like?

Aspect-oriented programming methods today have gained a significant following in the area of object-oriented high-level programming languages since their invention more than ten years ago. More recent developments have also found use cases for AOP in procedural programming languages operating at the system programming level. However, if one digs further down towards the hardware layer, only few signs of AOP usage can be found so far. This paper motivates the use of aspect-oriented approaches in hardware development, which today is mostly done in domain-specific hardware description languages (HDLs). These languages deviate from the programming language model by providing explicit notions for concurrency and time, resulting in synthesizable circuit descriptions that can be turned into a piece of hardware. A survey of crosscutting concerns in hardware descriptions and a first definition of join-points and pointcuts for HDLs is augmented by an aspect-related analysis of a production-quality hardware component and an overview of current developments regarding AOP and hardware development.

Psi-Pervasive Services Infrastructure

Future systems have been characterized as ubiquitous, pervasive, and invisible. They will consist of devices that are diverse in size, performance, and power consumption. Some of these devices will be mobile, posing additional requirements to system software and applications. The focus will move from technology to deployment and ease of use of services. Consequently, traditional paradigms for reasoning about, designing, and implementing software systems and services will no longer be sufficient. We believe that this future vision will rely on a three-tier infrastructure consisting of back-end servers, infrastructure servers, and front-end clients (mobile or static, handheld or embedded). The critical question for future systems will be how to deliver services on demand from back-end servers to resource-constrained clients. If we can handle the new requirements of these systems, we can enable this computing infrastructure to offer significantly more services to users in a more pervasive way.