MetaJava - A Platform for Adaptable Operating-System Mechanisms Michael Golm, Jürgen Kleinöder April 1997 TR-I4-97-10 Technical Report Computer Science Department Operating Systems — IMMD IV Friedrich-Alexander-University Erlangen-Nürnberg, Germany Presented at the ECOOP 97 Workshop on Object-Orientation and Operating Systems, June 10, 1997, Jyväskylä, Finland MetaJava - A Platform for Adaptable Operating-System Mechanisms Michael Golm, Jürgen Kleinöder1 University of Erlangen-Nürnberg, Dept. of Computer Science IV Martensstr. 1, D-91058 Erlangen, Germany {golm, kleinoeder}@informatik.uni-erlangen.de Abstract to languages and run-time systems have been implemented 1 to support some of these mechanisms. But this solution does Fine-grained adaptable operating-system services can not meet the very diverse demands, different applications not be implemented with todays layered operating-system make on such mechanisms. Instead it is desirable to provide architectures. Structuring a system in base level and meta an application with means to control the implementation of level opens the implementation of operating-system ser- its run-time mechanismans and to add own modifications or vices. Operating-system services are implemented as meta extensions if necessary. Reflection is a fundamental concept objects and can be replaced by other meta objects if the to get influence on properties and implementation of the application object requires this. execution environment of a computing system. Smith’s work on 3-LISP [Smi82] was the first that con- 1 Introduction sidered reflection as essential part of the programming model. Maes [Mae87] studied reflection in object oriented This paper describes the MetaJava system, an extended systems. According to Maes reflection is the capability of a Java interpreter that allows structural and behavioral reflec- computational system to “reason about and act upon itself” tion. and adjust itself to changing conditions. Metaprogramming MetaJava was built to achieve the following goals: separates functional from non-functional code. Functional • It must be possible to separate the functional, applica- code is concerned with computations about the applica- tion-specific concerns from non-functional concerns, tion’s domain (base level), non-functional code resides at such as persistence and replication. the meta level, supervising the execution of the functional • The architecture must be general, that means several code. To enable this supervision, some aspects of the base- problems, such as persistence, distribution, replication, level computation must be reified. Reification is the process synchronization must be solvable in it. of making something explicit that is normally not part of the The paper is structured as follows. We first introduce the language or programming model. The advantages of the concepts of reflection and metaprogramming in Section 2 separation in base level and meta level are outlined in and the computational model of MetaJava in Section 3. Sec- [KlG96]. tion 4 explains how object-oriented meta-level architectures As pointed out in [Fer89] there are two types of reflec- can be applied to the structuring of operating systems. Sec- tion: structural and behavioral reflection (in [Fer89] termed tion 5 shows the problems that had to be solved during the computational reflection). Structural reflection reifies struc- implementation of MetaJava. Section 6 discusses related tural aspects of a program, such as inheritance and data work and Section 7 concludes the paper and suggests future types. The Java Reflection API [Sun97]is an example of work. structural reflection. Behavioral reflection is concerned with the reification of computations and their behavior. The main 2 Reflection and Metaprogramming focus of MetaJava is to provide behavioral reflection capa- bilities. This is described in the next section. In the past, programs had to fulfill a task in a limited com- putational domain. As applications have become increas- 3 Computational model of MetaJava ingly complex today, they need more capable programming models that support run-time mechanisms, such as multi- Traditional systems consist of an operating system and, on threading (synchronization, dead lock detection, etc.), dis- top of it, a program which exploits the OS services using an tribution, fault tolerance, mobile objects, extended transac- application programmer interface (API). tion models, persistence, and so on. Many ad hoc extensions Our reflective approach is different. The system consists 1. This work is supported by the Deutsche Forschungsgemeinschaft of the OS, the application program (the base system), and DFG Grant Sonderforschungsbereich SFB 182, Project B2. the meta system. The program may not be aware of the meta 1 A base object also can invoke a method of the meta meta system object directly. This is called explicit meta interaction and is M2 M used to control the meta level from the base level. 4 Not every object must have a meta object attached to it. M3 M1 Meta objects may be attached dynamically to base objects at run time. This is especially important if a distributed com- event putation is controlled at the meta level and arbitrary method reflection (reification) arguments need to be made reflective. As long as no meta base system objects are attached to an application, our meta architecture A does not cause any overhead. So applications only have to pay for the meta-system functionality where they really B C need it. Currently meta objects can be attached to references, The computations of objects A,B,C raise an event that transfers objects, and classes. If a meta object is attached to an object, control to the meta level. the semantics of the object is changed. Sometimes it is desirable only to change the semantics of one reference to Figure 1: Computational model of behavioral reflection the object — for example, when tracing accesses to the ref- system. The computation in the base system raises events (see Figure 1). These events are delivered to the meta sys- void attachObject (MetaObject meta, Object base) tem. The meta system evaluates the events and reacts in a Bind a meta object to a base object. specific manner. All events are handled synchronously. Object continueExecution (EventMethodCall event) Base-level computation is suspended while the meta object Continue the execution of a base-level method. This calls the processes the event. This gives the meta level complete con- non-reflective method. No event is generated, otherwise the trol over the activity in the base system. For instance, if the reflection would not terminate. meta object receives a enter-method event, the default Object doExecute (EventMethodCall event) behavior would be to execute the method. But the meta Execute a method. Contrary to the previous method, this one object could also synchronize the method execution with calls the method as if it were called by an ordinary base another method of the base object. Other alternatives would object. be to queue the method for delayed execution and return to Object createNewInstance (EventObjectCreation event) the caller immediately, or to execute the method on a differ- Create a new instance of a class. The class name is passed as ent host. What actually happens depends entirely on the String (as part of the event parameter). meta object used. The currently defined events are listed in void installBytecode (Object ref, String method, byte code[]) Figure 2. Installs code as new method bytecode. Together with addConstantPoolItem this method is used to generate a enter-method(object, method, arguments) stub method in the place of the original method. method is being called at object with arguments String retrieveObjectLayout (Object ref) load-class(classname) Returns the types of all fields of object ref. This method is class classname is being used for the first time and used together with getFieldObject, getFieldInt, must be loaded getFieldFloat, setFieldObject, etc., to access fields of arbi- trary objects. create-object(class) Object getField (Object ref, String fieldName) an instance of class is being created Returns the contents of field fieldName of object ref. Name acquire-object-lock (object) and type of all fields (object layout) can be retrieved with the lock of object is being acquired retrieveObjectLayout. release-object-lock(object) void setField (Object ref, String fieldName, Object obj) the lock of object is being released Sets the contents of field fieldName of object ref to object obj. read-field (object, field) the field of object is being read int addConstantPoolItem (Class c, CPItem i) Adds an item to the constant pool of class c. write-field (object,field, value) value is being written into the field of object Figure 3: Selected methods of the meta-level interface of the MetaJava virtual machine Figure 2: Events generated by base computation 2 erence, or when attaching a certain security policy to the ref- erence [Rie96]. Attaching a meta object to a class makes all instances of the class reflective. To fulfill its tasks the meta object has access to a set of MetaJava VM methods which can manipulate the internal state of the vir- tual machine. These methods are called the meta-level inter- 2 face (MLI) of the virtual machine . A list of the most impor- give memory to give CPU time to tant methods of the MLI is given in Figure 3. 4 Metaobjects for open operating-system Memory Mgr. Scheduler implementations Garbage Collector In a Java environment, most mechanisms and policies that are traditionally regarded as operating-system or run-time– give CPU time to system services, are provided either by the virtual machine itself or by native libraries. As these services are imple- mented in C and the flexibility and comfort of a Java envi- ronment is not available for them, it is not easy to adapt Scheduler1 Scheduler2 them to special application needs or to transparently add RMI-handler1 RMI-handler2 new services. MetaJava provides an architecture for an open implementation of most mechanisms and policies that are method- execute thread in invocation currently a fixed part of the virtual machine, such as mem- event App.