Using Compile-Time Reflection for Object Checkpointing 1 Marc-Olivier Killijian, Jean-Charles Fabre, Juan-Carlos Ruiz-Garcia LAAS-CNRS, 7 Avenue du Colonel Roche 31077 Toulouse cedex, France {killijian, fabre, ruiz}@laas.fr Abstract. This paper tackles the problem of checkpointing object oriented programs using a reflective approach. The objective of the technique and the corresponding tool is to provide checkpointing methods to application classes. In conventional object oriented fault-tolerant systems, the implementation of these methods to save and restore the state of objects is often delegated to the application programmer; the dependability of the system relies thus on his ability to implement these core functions. Our approach enable the automatic provision of these methods for classes that obey some programming restrictions. In a second step, we present an optimization of this technique using runtime reflection; the data checkpointed corresponding to the set of attributes that have been modified since the last checkpoint. Some preliminary results of the evaluation of these techniques and an overview of the CORBA system framework in which they are used is finally described. 1 Introduction The definition of application checkpoints is a major issue in the design and the implementation of dependable systems, especially for building fault tolerance strategies. Checkpointing the state of individual active objects is always needed for many replication strategies and mandatory for cloning a new replica during the reconfiguration of the system after a failure. The problem of checkpointing a distributed application involves complex algorithms to ensure the consistency of the distributed recovery state of the application. All these algorithms make the assumption that individual checkpoints of the application objects can be obtained easily. However, this is a strong assumption and, in practice, it is not so easy when complex active objects are considered. The available solutions either rely on very hardware or operating system dependent mechanisms or delegate this task to the application 1 This work has been partially supported by the European Esprit Project n° 20072, DEVA, by a contract with FRANCE TELECOM (ref. ST.CNET/DTL/ASR/97049/DT) and by a grant from CNRS (National Center for Scientific Research in France) in the framework of international agreements between CNRS and JSPS (Japan Society for the Promotion of Science). 1 / 20 programmer. These solutions have many drawbacks and recent approaches investigate the use of compiler-assisted checkpointing techniques [9, 15] . The proposed solution can be compared to the later and shows that compile-time reflection is a promising approach to tackle the problem of obtaining the state of individual objects. This state information is here obtained at a high level of abstraction and handled through the combined use of both compile-time and runtime reflection. The technique proposed here is part of the definition of a metaobject protocol for implementing fault tolerance in CORBA applications [8] , although its use is not restricted to this topic. Obtaining the state of an object is part of this MOP but is also useful for other aims, e.g. object migration in mobile systems or simply for load balancing. In this paper, we investigated this problem for object-oriented programs; the real question is what is the state of individual object oriented programs? This state is required to resume execution on a remote system. After a brief analysis of current approaches and an introduction to our solution (Section 2), we describe a new approach to the object state capture using compile-time reflection. Indeed, using class definitions and implementations at compile-time, we are able to generate automatically methods, such as SaveState and RestoreState, responsible for the capture and restoration of the state of objects of this class (Section 3). An optimization of this approach using runtime reflection is then proposed: thanks to runtime information, we are able to checkpoint only the attributes that have been modified since the last checkpoint (Section 4). A comparison of our approach with a conventional non-reflective compile-time solution illustrates both the performance efficiency and the coverage of the state capture (Section 5). Section 6 gives an overview of the system in which these mechanisms are presently used. 2 Problem Statement and Related Work The available techniques to obtain the state information of an object vary very much regarding the abstraction level where they apply and of course depend on the real information that is needed. The state information of an active object encompasses two kind of information, the internal state of the object (namely state variables) and the information in transit (invocation messages). We concentrate here on the internal state, the latter dealing with end-to-end communication protocols not described in this paper, see [5] . The internal state of an active object is mapped at a very low level to memory objects (segments, regions, etc.) which are handled either by the operating system or better by a middleware (the runtime layer for the application objects). Understanding the mapping implies diving into the operating system or the middleware to identify which memory objects hold the internal state of a given application object. This approach often leads to a customization of the software runtime layer in order to obtain such detailed information. This is a first drawback of this solution since off-the-shelf runtime layers cannot be used in this case. A second drawback of this solution is that it provides raw information concerning the state of an object. It is worth noting that such information is not appropriate to install and initialize a newly created object on a different site of the system for following reason: 2 / 20 1. Some data items are not significant on a different site since their value is very site dependent (e.g. pointers to objects, file descriptors, semaphore descriptors, etc.) 2. The semantics of state information variables must thus be interpreted in order to perform an appropriate initialization of such variables on a remote site. Indeed, some data items are related to internal objects within the middleware of the remote site; a raw copy of the memory objects is thus not consistent on the target site and some additional actions must be performed. These actions must create and initialize the corresponding internal objects within the runtime layer of the remote site. As soon as these actions complete and that the new instance is updated with the current state information, then the new object copy holds a consistent state from which the computation can continue. Such important observation indicates that semantic information regarding such data items is necessary to obtain a consistent checkpoint for the new object copy. Another approach consists in providing the user with libraries of functions [14] or classes [10, 11, 13] to deal with fault tolerance protocols and state information. In object oriented terms, the application classes must inherit from some base class in which the two methods SaveState and RestoreState are defined as virtual methods. This second approach is clearly not transparent for the user and relies on user’s skills to use the library functions or to implement the virtual methods correctly. This means that the implementation of both methods must be error-free. For instance, a wrong implementation of the SaveState function will lead the new copy to hold an inconsistent state from which the execution could not be restarted. This is a major drawback of such solutions. Moreover, since the implementation can be very difficult for very complex objects the probability of introducing software faults (bugs) in so doing is certainly very high. Another side effect of such solutions is that any modification (evolution) of the application object implementation must be consistently reported to the SaveState and RestoreState implementation. Because different application programmers can perform the long-term evolution of such application objects, a consistent implementation of these methods is not guaranteed during the lifetime of the application. Clearly, in the short or in the long term the whole distributed application will fail. It is worth noting that the definition and the implementation of such core functions must be tool assisted. Following this idea, some works have investigated the use of customized compilers to generate these functions automatically, e.g. [15] . More recently, the use of compile-time reflection was introduced to tackle this problem [7, 8] . In this type of solution, the identification of the internal state of application objects is very language dependent. This is however the only way to obtained detailed information about the internal state of application objects on off-the-shelf runtime systems. Any other solution would provide a coarse view of this information and make the interpretation of site-dependent objects very uncertain. A language independent solution would require the runtime system (the middleware, e.g. the ORB) to reify such detailed information, i.e. making the runtime system reflective. Both solutions rely on a reflective approach, the latter involving anyway a customization of the runtime system or the use of an appropriate reflective runtime system (only the Java runtime system provides type information using the java.lang.reflection package). 3 / 20 It is worth mentioning that pure object-oriented languages are easier to handle with this approach rather that hybrid languages such as C++. However, the experiments reported in this paper have been performed for C++ objects and the tool based on Open C++ [1] . This is why some programming conventions and restrictions have been considered in order to enforce a strong encapsulation principle and avoid programming statements that may lead to uncontrolled side effects to the object state. The necessary restrictions would have been very different using Java. We will comment on this point later, in section 4.3, but programming restrictions are not a real problem from our viewpoint.