Compilation of Object Oriented Languages Tik Compilers Seminar

Transcription

1 Compilation of Object Oriented Languages Burlacu Mihai Helsinki University of Technology Abstract The paper covers briefly the object-oriented concepts, usability and advantages of using object-oriented languages. The paper will focus mainly on the particularities concerning compiling of object oriented languages. The general compilation techniques that might not follow the OOP compilation specific, and are common for every basic compiler are not covered. Special emphasis is put on compiling multiple inheritance. Issues like optimizations and private/public visibility of object information is also covered briefly. 1 Introduction The structure of the paper is the following. First, the general concepts of object oriented languages are presented. Then special techniques employed in order to compile OOP languages are presented. As the classes are mainly simple data structures "wrapped" with handling methods, compiling class variables does not require any new extra special techniques. A general compiler implementation (with little modifications) should handle without difficulty state variables. Special handling is required for methods, for inheritance, etc. Multiple inheritance rises many difficult issues during compilation, and will be treated in detail. For multiple inheritance different compiler implementation alternatives are studied. In the last part of the work optimization techniques are discussed. Also encapsulation specific issues are presented. 2 General Aspects Concerning Object Oriented Programming 2.1 Classes, Objects Object oriented programming appeared from the need to give a better control and hierarchy to the code. Initially, imperative source codes were written similar to assembly programming. No hierarchic structure, data accessible directly from anywhere, difficulty to understand program structures were factors that leaded to object oriented thinking. Abstraction, extensibility of modules, abstraction and modularization are new areas that can be efficiently handled using object-oriented thinking. Also it is much closer to human perception. The new concept of object was introduced to deal with need to have functions and data structures as a single unit. It is a direct consequence of modularization. An object contains a set of variables (state variables) and the corresponding interface functions needed to handle the state variables and implement the external behavior of the object. The functions are known as object methods. Briefly, an object encapsulates both data and operation on the data. Classes are 1

2 the blueprints of the object, specifying the general structure. The object is an instantiation of a class. 2.2 Inheritance, Polymorphism and Specific OO Rules Inheritance is the well-known term for extensibility of modules. If a new class needs to have all the features (state variable and methods) of a base class, then it will inherit all these features from it without the need to rewrite all the code that already exists in the base class. The inheriting class is also known as derived class, and the inherited class is known also as base class. It is allowed that derived class to overwrite (redefine) the methods of the base class, even if the method might have the same declaration prototype. Polymorphism is the property that a particular object can be viewed and used as if it would have more (poly) types. Those multiple types are in fact the types of the base classes from which our object is derived. The rest of the paper will use extensively this concept (although not specifically written). The views used to describe inheritance compilation from next section is a good example. In this paper, the discussion will require familiarity with the following rules Inheriting Rule: If a class B inherits from a class A, then the type assigned to B is a subtype of the type assigned to A. Every object of inheriting subtype (B) will be automatically a supertype element (A) Subtype rule: If inside a declaration a superclass type is used (or a return value of type A is expected), then it is allowed to pass any subtype B objects as actual instance for the expected A class object. Briefly, this means that it is allowed to pass an inherited object b in places wherever base class type objects are expected ( A type) Method selection rule: If a class B inherits from the class A and overwrites method m, then for B type object b, the definition of m provided in the class B must always be used. Also in the case when b is used as an A object. Last rule will make compiling more complicated as we shall see in the next sections. It requires dynamic binding. Dynamic binding is the case when we can not bind the method to a specific definition, since at compile time the final type of the object is not known until runtime. And only at runtime, we will know the actual type of the object and call the correct definition of the method, that might have been redefined in the derived class. It must be possible to bind a method m statically if at compile time we cam determine the final type of an object o. We assumed o to be an instance of a derived class that redefined the method m. If it is not possible to determine the final type of the object at compile time, then the binding of the method must be done dynamically. 3 Compilation Techniques Compilation techniques are not fundamentally different from compiling traditional imperative languages. That is why, mainly the OOP language compilers uses in a great manner the basic compiling techniques, adapted to fit the new requirements of the OOP. In the following part we will explain in detail the compiling particularities derived from OOP requirements. A special focus will be on presenting the compilation of methods, schemes for compilation the inheritance. Genericity issues will be covered in the next chapter. 2

3 3.1 Techniques for Compiling Methods of the Objects Methods are essentially compiled in a similar mode to imperative languages. They are compiled into machine code and placed into instruction space at a particular address (the address of the entry point in the function). It is aimed that, during compilation, to equivalently transform the object s methods declaration and definition into imperative programming functions. After that, the resulting functions can be compiled using standard compilation techniques employed in traditional compilers. Next, it will be presented the procedure to map object methods to basic functions. Consider the method method-a of the class class-a. For this method we might have the following declaration: returntype method-a (argslist) Then, the function fa equivalent to a would have the following prototype: returntype fa ( class-a this, argslist ) For exemplification it is used the C++ language semantics. Any OOP language could have been chosen for exemplification -like Java - but, in C++ the internal mechanisms are better visible. The method call is also translated into a traditional format. To show this, assume objinstance- OfA to be a instance object of the class A that has the method a. By assuming that a method of class A is not a static function, the function call in the source code would look like: objinstanceofa.method-a( argslist); The equivalent function call would look like: fa (objectinstanceofa, argslist); Object oriented languages requires the possibility to have methods with the same name within the same class. In such circumstances, the possibility to separate the methods is based on their return types or/and the different number(or types) of the parameters passed in the argument list of the function. In C++, Java etc, this feature allow an elegant implementation for the object constructors, as it is not necessary to have only one complicated constructor, but allows having more versions for the constructors, much simpler and clear. We can have methods with same name when the difference is made by different number of parameters passed as arguments. In case the difference is made by the types of the parameters passed as arguments, then checking the template usage solution would worth investigating. This template approach will be later detailed in the Genericity chapter. This is the reason that naming for the equivalent function might incorporate also information about the number and types of the arguments list parameters. An example will be shown next. Until now it was presented the possibility of translating the OOP specific function format into the classical imperative programming format. Next, it will be presented the possibility on how the compiler internally might rewrite the functions in order not to bother anymore with the object-oriented ideology. Bijective (one to one) mapping is essential at this stage, as the OOP specific information must be preserved. We will end up in the situation that the name of the method itself is not used alone as the name for identifying internally the function. By keeping this in mind, the first requirement is that the functions to be bound to the class they belong to. Appending to the class name the method s name is a straightforward solution. By adding the class name in the internal function identifier, we ensure that different classes can share the same name for the methods without the danger of colliding. In the specifications, each class has its own namespace and there should not be conflicts between the name spaces. Inside the same class can be methods with same names but different parameters (and imple- 3

4 mentations). Then, when build the internal function identifier (new name), it is added also the information for the arguments from the declaration. A simple C++ example is given below: Assume we have the class Mathematical-Oper with two methods add. There are two possible definitions for "add". One would be: int add (int a, int b) return a+b; and the other would be: double add (double a, double b, double c) return a+b+c; Internally the functions can be identified as: add-mathematicaloper-intint (...) add-mathematicaloper-doubdoubdoub(...) In this case, any compiler should have the correct function mapping to deal with. 3.2 Techniques for Compiling Inheritance Next it will be performed the analysis of both simple and multiple type inheritance. This will be detailed in the next two sections. In the first section simple inheritance is evaluated, while in the second section it is evaluated multiple inheritance. The multiple inheritance section is covering the cases of dependent and independent multiple inheritance. Specific issues and pitfalls emerging in those situations are presented. Special attention is put on the views of an object. If a class B inherits a class A, then a B type object can be used (almost) everywhere where A type objects can be used. In order B objects to be viewed as A objects, the compiler must be able to generate an A view of B objects. During runtime, even if we expect an A view for a function argument or return value, compiler still needs to be prepared to activate the correct method defined in the B class, in case the real object is of type B - although we pass a B type object to a parameter initially defined as A type. 4 Simple Inheritance In simple inheritance a class can inherit from at most one class. Generally, each class descriptor contains a pointer to its parent class and a list of method instances. Each method instance has a machine-code label. Generally, methods in a class can be declared to be static or dynamic. [1] Static methods are class specific and NOT object specific. They are compiled like it was presented in the above section for method compiling. Dynamic methods require special handling, because dynamic methods of base classes can be overridden in the derived classes. So, implementing the dynamic bindings efficiently is a key requirement and deserves detailed explanations. For each class the compiler creates a virtual method table. The method table includes all the methods defined in the class that might have to be dynamically bound (nonstatic methods). The table contains entries for all methods of a class (and superclasses if any) that are defined to be virtual. Each object includes as its first component a pointer to the method table corresponding to its proper class. Compiler binds method names to indices in the method table. When a method is called, it is activated the function stored under the corresponding index in the method table. [2] To build the method table for an inherited class, first, it is copied the method table of the base class. In this copy, redefined methods are overwritten by the new definitions. The new methods are simply appended to the base class table. [2] 4

5 Concerning the variables of the class, the prefixing technique is used. If the B class inherits A, the fields of B that were inherited from A are put in the B record at the beginning, in the same order they appear in A records. Fields of B not inherited from A are placed afterwards. 5 Multiple Inheritance Languages supporting multiple inheritance should allow a class to inherit from multiple base classes. In this case the class diagram will not be a tree structure like in simple inheritance, but directed acyclic graphs. Two compiling techniques for dealing with multiple inheritance in case inheritance from base classes is dependent/independent is presented in the next two subsections. Next, specific problems (and solutions) that may arise in multiple inheritance cases are analyzed. Assume the classes B1 and B2 are both base classes for the class C.Generally, problems may arise if: **(a)** The same name for methods (or attributes) are used in the base classes, inheritance may have conflicts. **(b)** Repeated inheritance. If both B1 and B2 inherit the same class A, the C will repeatedly inherit the class A; this will generate a conflict. For the first problem (a) a possible solution would be to define one class (either B1 or B2) as the main ancestor, and solve all the conflicts in the favor of the main ancestor(i.e. the method or variable in question will be considered to belong only the main ancestor when dealing only with the class C). Other possible solution would be to specify the language in such a way it allows renaming of inheriting features and leave the programmer "by hand" to resolve potential conflicts (E.g. Eiffel language); The same idea is implemented in the C++ language. It is possible to explicitly specify which class::method( or variable) is desired to be used. If for example a method m is both in B1 and B2, then it is possible to unambiguously specify which definition (either B1 or B2) is used. In C++, invoking the method from a desired class can be done like B1::m. For the second problem (b) of repeated inheritance two solutions are available. One possibility can be to multiple instantiated the repeated inheritance, or other possibility, to keep only one instance of the repeated inheritance. Next picture illustrates this idea. Figure. Multiple instantiation (a) and single instantiation (b) of multiple inheritance 5

6 In some cases it is desirable that the common inheritance be multiply instantiated, while in other cases we require a single instance of the common inheritance. Schemes that permit multiple instantiation of multiple inheritance are simpler and produce more efficient code than single instantiation of repeated inheritance. 5.1 Compiling Schemes With Independent Multiple Inheritance In this case objects of the inheriting class C contain complete copies of the base classes B1 and B2. Every object contains a pointer to the method table for its class as the first component. Also we must keep in mind that it is required for the compiler to be able to generate B (base) views of C (inherited) object. The object C will be formed by appending to the information of the class B1 the information of the class B2, and then append the C class specific information. See the next picture for an abstract printout. Figure. Independent multiple inheritance structure. For this case two distinct approaches can be identified if considering the way method tables are constructed and structured: 1. One approach is to have a copy of the method tables for the classes that are multiply inherited (e.g. B2, but except B1 that will common with C), and form the B2 views of the C object using the copied method table for B2 2. The other approach is to have a single copy of method table for the multiple base classes. This requires storing the C method table in a distributed manner. Also recursively, it is possible for B1 and B2 to have distributed method tables. For the first case see the next figure containing the implementation view for multiple inheritance. The reason we need to copy the method table for multiple inherited classes (except the first one) in addition to the primary copy to which the C object is referring, is due to the requirement of possibility of viewing the inherited object C also as through any of its base classes Bx. Recall that we constrained the pointer to the method table to be the first element of the object C, or, if the Bx view of C is needed, the pointer to the specific method table for Bx should be in the head of Bx subpart from inside the C instance. 6

7 Figure. Object Structure with Method Table Copies for Each Multiple Inherited Class For the first base class B1 the simple inheritance view can be used. B1 view of a C object is the initial section of the C object. But for the next base class (B2) we can not use the same initial view of C, because that is B1 space, and we are constrained to have for B2 view first a pointer to the B2 method table, then followed by the attributes of B2. So, we create(copy) a new method table of B2, copy the original content, and override the methods that are redefined in the C class. Moreover, every entry in the method table must have in addition to the method itself also an offset. The reason the offset is needed follows the following fact. Assume C class derived from A redefines a method m from base class A. If we call a function from C, then, obviously, the function m expects to run in C environment (view). The function m, due to redefinition in C class will overwrite the entry from the original method table of A. Assume the function m is activated in A view. So, it is needed to calculate the C view from the available A view, since, even if the method m is activated in A view, it needs to be run in C view context. The offset provides the link between A view and C view. It is the offset of A subobject inside the C object. In this way, the view expected by a method can be generated from the view available at method activation. Briefly, each view is represented by the references to the corresponding subjects. This method has the drawback of having modified copies for each multiple inherited base classes (except first one). This increases the storage requirements, that is bad for some applications. This drawback is removed by the usage of the distributed method table approach. For the second case it is needed to have only one copy of the method table for each base class (B1, B2,... Bn). See the next picture for a graphical representation. 7

8 Figure. Object Structure with Single Method Table for Each Multiple Inherited Class of C In this case, we have the following situation: The C object composition is: the pointer to the C method table, the object components of the first class (B1) excluding the pointer to the B1 s method table (since it coincides with method table of C), object components of B2 and the attributes newly introduced by C Methods of class C comprises all the methods of the base classes and the new methods introduced by the class C Superclasses of C are considered to be the base classes B1 and B2 and C itself. Method tables. The method table of C is a list of modified copies of the base classes (Bx) method tables, extended at the end by the entries for the methods newly introduced by C. A entry in the method table of some base class (Bx) is kept unmodified if the class C does not override (redefine) the respective method. If a method from the base class is redefined in the derived class C, then the entry in the base class method table is overwritten with the information from the class C Bindings of C s object components to their corresponding offsets in C s object. The pointer to the C s method table has the offset = 0; This pointer and the pointer to B1 s method table are the same. For the components c (state variables) inherited from B1, the offsets of c in the C view are identical with the old offsets in the original B1 view. For the next multiple inherited class B2, the offsets of the components c from C view(state variables) inherited from B2 will not coincide any more with their original offset from within B2. They will be shifted by the size of B1. That is because variables inherited from B2 are appended in memory after the variables of B1 when building the C variable bunch. The offsets of the variables introduced newly by C are appended in memory after the variables inherited from B1 and B2, and hence the offsets of the new c components of C will be increased by the size of B1 plus the size of B2. Binding of methods to their position in the method table. If a method m was declared in the class B1, then it will be in B1 s method table. Considering m to C s method table, then m is the function m stored in B1 s method table section belonging to C. Briefly, the method m of C is in B1 s method table that originally declared m. If the method mc is declared newly in C class then the method mc will be in the new section of method table allocated for the functions newly introduced in C. The method table for C section newly introduced is appended to the method table of the first base class (B1). All the other tables for the other base classes (except B1) are distributely spreaded, and may not be put in order in the memory. Their corresponding subview pointer will be responsible 8

9 for reaching them. A method mb2 from B2 base class will be retrieved by the C view from the section of the method table of C corresponding to B2. The actual offset of the method mb2 relative to the head pointer of C (the 0 offset) will be computed as the sum of the offset of the method mb2 in the method table section of B2 plus the actual offset of B2 s method table relative to the C reference start (0 offset). 5.2 Compiling Schemes With Dependent Multiple Inheritance In this subsection we describe the case of dependable inheritance when both B1 and B2 inherit a common class A. In this situation the common inheritance will be passed to C as repeated inheritance. As we have already seen, in this case we might have multiple instantiation of the common class, or same instance for the multiple classes. We consider the case of one instance for common part of repeated inheritance. In this the common class instance will be practically contained into only one subinstance (say B1), and the other subinstance (B2) will have a gap corresponding to the *lost part* corresponding to A part that is now contained only in B1. This gaps will be visible when C inherits from B2, long after the compiler decides how a B2 view would look like. Hence, offsets of the components within the objects ARE NO LONGER CONSTANT and can not be bound statically. In this case using a look up table would be a straightforward solution. The compiler binds the components of a class to fixed indices in an index table. A separate index table is created for every different context to contain the offsets valid for that context. Also in this case the two mapping tables for C contain two copies of the index table of B2. An improvement would be to eliminate one copy of B2. The picture below describes the improved case. Figure. Object structure for general dependent multiple inheritance. The objects/subobjects contain a pointer to the relevant index table. In the picture above, the index table C-index assigns to every component (of C) its offset. This offset is relative to a C reference. In this case, we have the following situation: Object components of C contains the pointer to the C-index table, the object components of B1 without the pointer to B1 s index table(it is the same as the pointer to the C index 9

10 table), the object components of B2 without the common components with B1, and the newly components added by C Superclasses of C consist of the superclasses of B1, B1, superclasses of B2 (!that are not also superclasses for B1 -common superclasses), B2 itself, and C itself 6 Genericity Keeping things generic tends to contradict the principle "of performing as many checks as possible at compile time and not at runtime". Having dynamic type checking escapes many programming errors that would have been found during compile time if we would have the type check verified at compile time. That s why compile time type check is recommendable. There are many cases when we need to implement a generic procedure, and only at run time the correct type for the processed parameters is available. If we can not choose at runtime the data type to deal with, then we end up with the requirement to implement the same algorithm with many instances, depending on how many data types we need to support. In case the algorithm is complex and with large size we will end up having big executable code, source files, and more, maintainability difficulty. So, the generic data type (generic class) concept was introduced. It is a type/class prototype with formal parameters. It allows to specify an algorithm with abstract (general) parameters datatype. When we will know the precise data type of the parameters we want to use, then we will pass as arguments to the algorithms. In that case, the compiler will be able to update the generic data type with the real data type. And the flow of the algorithm will be performed with the generic types replaced with the current type. A simple example is the function add. If using strong type programming, we would need to have: add-int(int, int); add-float(float, float) etc. By using a template for the function add(astractdatatype, abstractdatatype), we can have only one method add, and in case we need to add 2 integers we pass the add function two integers as parameters. Eg. add(7,8) In C++ the definition of a generic class is done using the keyword "template" followed by the formal parameters. When instances of a generic definition are referenced, the generic definition is used as a pattern from which to generate a concrete class/function given the actual parameters. In this moment the definition is allocated (expanded). It is the task of the C++ compiler to do the create and fill work for the actual instance. If a generic definition is multiply instantiated with different parameters, then the generated program contains multiple instances of the class/function. This may cause the program to have its size highly increased. By contrary, in Eiffel programming language, the generic class is compiled directly into target code and the implementation of its methods can be used for all instantiations of a generic class. So in Eiffel implements each of its instantiations with a single instance of a generic definition. One might think to take advantage of the inheritance, to make a base class where we implement all the needed generic algorithms for all objects, and then use a new class that inherits the base class. In such a way, it might be thought that the generic methods would be readily available in the new derived object. But, in this case the generic methods from the base class are unusable. As there are places where an object can not be replaced by an object of a subclass. The assignment type rule ( := ) is an example for this. 10

11 7 Information Encapsulation. Private Fields and Methods Objects need to hide their internal implementation. Also it is preferred that objects of different classes should not be allowed to manipulate the state of an object (the variables of an object) directly. It is preferred to use the methods of the object interface to change the internal variables. A private element is an element that is not possible to be fetched/modified from outside the object. Also a private method is allowed to be called only by the objects methods. Privacy is enforced in the type-checking phase of the compiler. Internally, a Boolean flag is used to indicate whenever the field is private. Usually these privacy declarations are static and can be interpreted always during compile time. 8 Optimizing Object Oriented Programs Beside the general optimization problems that are specific to any programming language, for object oriented languages we might have optimization derived from OOP specific structure. A sensible point for compiling OOP languages is the existence of dynamic methods. It is desirable to convert the dynamic method calls to static method-instance calls. An optimizing compiler does global source analysis to determine the places where a method call is always calling the same method instance. In that case the dynamic method call can be replaced by a static function call. Also if a method m is defined in a base class A, then it is searched through the hierarchy of the class A for all the derived classes B, C... that might override the method m. If no derived class overrides the method m, then it is assumed that A-m will be always instantiated, no matter the type of the object (from base or derived class) that might call the respective method m. E.g. if D inherits A, and objd is an instance of the D class, then the call objd.m will call the instance A-m. 9 Conclusions Object oriented languages do not fit applications that requires small memory usage (embedded systems) since requires dynamic memory allocation and lots of memory. Programmer is responsible for memory release (e.g. C++), and the possibility to encounter errors is high. If the compiler is responsible for clean up (Java), the result is bigger code, and memory clean up may slow down the execution irregularly. And moreover not always the object oriented thinking solves the problems in the easiest manner. In simple inheritance (and also independent multiple inheritance) dynamic binding requires addition of a pointer to method table per object. The disadvantage of dynamic binding is the increase in the runtime for a method call, because of dereferencing a pointer to find the method table and indexing to locate the method to be activated. Referring to multiple inheritance, the two cases - dependent/independent classification - we cam summarize the following results. In general the performances are quite similar in both cases. From the point of view of runtime cost for method activation, the dependent approach is a little slower (7 machine instructions compared to 6 machine instructions for independent case). Consider storage overhead per class the performances are the same, as the size of the tabels increases linearly with the size of the class definition. Storage overhead per object is done by the addition of the extra pointer to the index-table/method table as overhead. 11

12 References [1] Prabha Gopinath, Thomas Bihari, Rajiv Gupta Compiler Support for Object-Oriented Software IEEE Computer Society [2] R. Wilhelm, D. Maurer Compiler Design Addison-Wesley, 1995 [3] A. Appel Modern Compiler Implementation in Java Cambridge University Press, [4] B Stroustroup The C++ Programming Language Addison Wesley Publishing 12