Phoenix
Research
The Operating Systems and Middleware Group is being supported by Microsoft Research in the research of new applications for the Microsoft Phoenix software optimization and analysis framework.
Phoenix for .NET Aspect Weaving
User-defined attributes within the .NET environment allow for tagging language elements with additional information. They have become a widely used and well accepted technology. Throughout .NET, attributes are used to express non-functional properties such as the Serializable attribute which mark a class serializable. Unfortunately the semantics of such attributes is currently described in an informal fashion only. In particular, there is no way to give such attributes additional user-defined behavior. All behavior behind certain attributes is defined within the environmental framework. I.e. the serialization attribute.s behavior is defined in the .NET framework. Extending the framework to support new attributes with behavior is not readily available yet.
We propose an extension of the idea of user-defined attributes based on the technique of aspect-oriented programming (AOP). AOP was developed to solve the problem of crosscutting concerns. The problem of crosscutting leads to tangled and scattered code. Using AOP it is possible to separate every concern from each other and implement them in discrete units, so-called aspects. Our idea is that attributes with behavior can be seen as aspects: Attributes (aspects) are used to define a non-functional property including the required code. If a language element (which can be an assembly, a module, a class, or a method) is tagged with an aspect, this language element becomes interwoven with this aspect.
Phoenix in our case acts as an intermediate language aspect weaver. Input for the weaver will be a regular .NET-assembly (target assembly) which uses aspects as attributes. The result are two assemblies: a rewritten assembly which references to the interwoven code exactly to these points where aspect attributes were tagged to language elements, and an additional assembly which contains the interwoven code.
For more information on aspect weaving with Phoenix, go to the LOOM.NET website.
Domain-specific languages for safety in the Distributed Control Lab
The Distributed Control Lab (DCL) provides an open infrastructure for conducting robotics and control experiments from the Web. Users of the DCL can write a control algorithm that can be executed on the physical experiments. Live cameras provide feedback remote users. The lab infrastructure has been successfully integrated into lectures of programming embedded systems including remote lectures at Blekinge Tekniska Högskola in Sweden in Fall 2006. Beside the evaluation of real-time operating systems and programming environments, among them Windows Ce.Net and the .NET Compact Framework, the implementation of real-time control algorithms and low-level programming are studied.
Within the DCL environment we focus on safety strategies and mechanisms in order to prevent malicious code from damaging experimental equipment. These include source code analysis, domain-specific languages, .NET code access security, runtime observation and the dynamic replacement of faulty control algorithms. Analytical redundancy is used to predictably replace malicious control algorithms by a verified safety controller during runtime. This technique has already been proven in several contexts, the most frequently cited use case is actually the Boeing 777 flight controller.
In order to effectively integrate these techniques into our remote lab infrastructure we have implemented tools and a runtime environment supporting dynamic replacement and online monitoring of control algorithms. During the compilation of user control algorithms additional instructions are added with these tools. In order to improve the safe execution of potentially malicious code, we are going to use new compiler tools, including the Phoenix compiler.
For the integration of configuration-specific concerns, needed for analytical redundancy, we use our aspect weaver Rapier-Loom.Net. Rapier-Loom.Net supports aspect-oriented programming paradigms for the .NET framework and is currently using Reflection functions. The runtime performance of Rapier-Loom.Net can be improved by using Phoenix Compiler Features.
For our robotic control experiments we exploit domain specific languages to protect our experiment hardware. Using Phoenix we are able to restrict programming languages. Dangerous construct such as recursion or direct pointer manipulation can be limeted. Using this techniques we are able to provide a high availability of our lab experiments.
Phoenix for Embedded Systems Code Optimization
The Micro .NET project focuses on executing .NET/ECMA 335 CIL on small embedded systems, which are not covered by existing .NET runtime environments (.NET, Rotor, Compact Framework, SPOT/.NET Micro Framework). These systems typically have limited resources, which prevents the usage of a full-fledged virtual machine, mainly reasoned by the comprehensive class library. Within the Micro .NET project, we investigate execution environments and assembly formats for environments with minimal memory (32kb-256kb). Static linked assemblies are seen as an approach to minimize the memory footprint on the embedded system. The Phoenix framework offers us possibilities to create such optimized assemblies.
In the first step the targeted assembly and the relevant library features are combined into a self-contained binary. The resulting assembly does not require any additional library provided by the CLR. The memory footprint reducing depends on the number of unused features in the former relevant libraries. As a side effect, the process of dynamic linking of features is optimized. The second step evaluates the self-contained assembly to identify unused type features, which may be removed completely or can be represented without CIL code, while preserving the type layout. The output of this transformation may be an optimized binary assembly representation, like in the .NET Micro Framework.
The Phoenix Framework offers us a rich set of functionality to build the Micro .NET tool chain. We are investigating the combination of the .NET language compiler and the Micro .NET tool chain on top the Phoenix technology in our ongoing research.
Phoenix for Dynamic Windows Research Kernel Code Visualization
With the advent of the Windows Research Kernel (WRK), Microsoft released the core part of Windows Server 2003 source code files. This resource will be used in our lab experiments to introduce the Windows operating system to our students.
Understanding the kernel itself is already a challenging task and requests assistance from powerful tools as the Phoenix project. We use Phoenix to develop enhanced analysis tools that instrument certain aspects of the kernel to trace execution flow and to deduce design principles.
The figure shows a graph resulting from our instrumentation. The components of the graph are as follows:
- Ellipses denote thread objects and contain the process and the thread identifier in that order.
- A yellow rectangle denotes a waitable kernel object, e.g., semaphores or mutexes, etc. The rectangle contains the type of the waitable kernel object as well as the address of this object.
- A directed edge from thread A to object B denotes that A waits on B. The weight on this edge indicates the number of times a thread waited on this object.
Originally, these events were traced in a modified, instrumented version of the WRK, called Windows Monitoring Kernel. Phoenix now offers the opportunity to instrument an existing unmodified Windows kernel by modifying the PE file of the kernel. Insights resulting from the WRK can therefore be brought to COTS versions of the Windows kernel.
Insights from kernel analysis will be used to develop new operating system abstractions to support service-based systems. For more information on service computing, see the HPI Research School website.