GOO: a Generative Object-Oriented Language

Transcription

1 Position paper for the ECOOP 02 workshop on generative programming GOO: a Generative Object-Oriented Language Ulrik P. Schultz Center for Pervasive Computing University of Aarhus, Denmark Wednesday 10th of April Abstract This position paper describes GOO, a generative object-oriented language. GOO is based on automatic program specialization principles intimately integrated with the object-oriented paradigm. The result is an object-oriented language well-suited for generative programming, where inheritance and virtual dispatches are used to drive the program generation process. In more detail, I give a few basic examples of using GOO for specialization and generative programming, describe the semantics of GOO, and outline the most important issues in designing a type system for GOO. 1 Introduction Template metaprogramming is a powerful mechanism that allows tailored programs to be generated from program parts parameterized using C++ templates [5, 19]. This technique has the advantage of being usable with any ANSI-compliant C++ compiler, and it guarantees that all configuration is performed by the compiler before the program is executed. However, the syntax used for template metaprogramming is far removed from standard programming languages, and the semantics more closely resemble that of a rewriting system than object-oriented programming. As an alternative to template metaprogramming, automatic program specialization can be used [14, 16, 17, 18]. Rather than expressing the generator program using templates, the generator program is implemented using standard object-oriented abstractions, and then specialized to obtain a tailored program. Specifically, the generator program is implemented as a generic object-oriented program, and specialization configures the program by optimizing away computations that depend on configuration information. Nonetheless, automatic program specialization suffers from poor predictability compared to template metaprogramming, and is not a perfect match for object-oriented languages since it relies on aspect-oriented programming to express configuration information as well as the resulting program [15]. In this position paper I describe a work-in-progress on an object-oriented language, named GOO, that integrates automatic program specialization. Unlike most other approaches to generative programming, GOO is driven by inheritance and lets the generator program be expressed using object-oriented abstractions. The rest of this paper is organized as follows: I first introduce GOO using a small example from automatic program specialization, then I discuss the semantics and type system of GOO, and last I investigate a more standard generative programming example using GOO. 1

2 class Power { op: BinOp; exp: int; int result = this.op.neutral(); int n = this.exp; while(n>0) { n = n-1; result = this.op.apply(result,base); return result; class BinOp { abstract int apply(i,j: int); abstract int neutral(); class Mul extends BinOp { int apply(x,y: int) { return x*y; int neutral() { return 1; class Add extends BinOp { int apply(x,y: int) { return x+y; int neutral() { return 0; Figure 1: The basic power program in GOO 2 GOO example: the power class Figure 1 shows the implementation of a power function in GOO. The Power class has fields exp and op which contain the exponent and the operator to apply, respectively. The operator is declared to be at least a BinOp, meaning that it can contain an instance of BinOp or any subclass. GOO allows covariant specialization of fields in subclasses similarly to the Beta language [10], so a subclass MulPower of Power could be declared as follows: class MulPower extends Power { op: Mul; Here, the operator has to be at an instance of Mul or a subclass. (Note that, unlike in Java, here it is the same field that is made more specific, not a new field which shadows the original one.) It is also possibly to specify a final binding, as follows: class MulPowerFinal extends Power { op:: Mul; Here, the operator can only be an instance of Mul, subclasses are not allowed. In standard object-oriented languages, such type declarations are used for typechecking purposes only. The core idea of GOO is to use the covariant type declarations to specialize the methods of the class when making a subclass, similarly to customization [3]. But unlike customization methods are specialized both for the type of the self and for the declarations on the types of the object fields. Thus, both the MulPower class and the MulPowerFinal class of the previous paragraph would cause the methods in 2

3 User code: class MulPower extends Power { op: Mul; Compiler-generated code: class MulPower extends Power { op: Mul; int result = 1; int n = this.exp; while(n>0) { n = n-1; result = this.op.mul::apply(result,base); return result; Optimized, compiler-generated code: class MulPower extends Power { op: Mul; int result = 1; int n = this.exp; while(n>0) { n = n-1; result = result*base; return result; Figure 2: Specializing the Power class, step 1 the Power class to be specialized for the information that the field exp is of type Mul (this information can be deduced for MulPower since Mul has no subclasses). This specialization is illustrated in Figure 2. User code is what the programmer writes, and Compiler-generated code is the code automatically generated by GOO. Optimized compiler-generated code is what a compiler trivially can generate based on the compiler-generated code. In the compiler generated code, the specialization process has resolved all virtual calls to this.op, which allows the neutral value to be propagated into the body of the method, and allows the apply method to be called using a direct method call (the syntax x.c::f(...) means call the method f of the class C with the object x as the self). A compiler can trivially inline the definition of the apply method into the raise method. A second important concept in GOO is to specialize not just for object types, but for any kind of value. To this end, GOO uses a generalized subtyping relation similar to Cardelli s power type [1], where concrete values are subtypes of the type they belong to. 1 For example, the constant 3 is a subtype of the type int, sowe can further specialize the MulPower class for a specific operator, as illustrated in Figure 3. Here, we specify that the exponent is the value 3, which allows the loop 1 Note that the term power type is unrelated to the arithmetic power computation used in the example. 3

4 User code: class MulPower3 extends MulPower { exp:: 3; Compiler-generated code: class MulPower3 extends MulPower { exp:: 3; result = this.op.mul::apply(1,base); result = this.op.mul::apply(result,base); result = this.op.mul::apply(result,base); return result; Optimized, compiler-generated code: class MulPower3 extends Power3 { exp:: 3; return base*base*base; Figure 3: Specializing the power program, step 2 inside the raise method to be unrolled. The result after optimization is an efficient implementation where multiplications are done directly three times on the base value. Since GOO is an object-oriented language, the generalized subtyping relation is also used for objects. Intuitively, an instance of a given class is a subtype of this class, and an instance of a given class is a subtype of any instance of any superclass of the class. In effect, the less is known about an object, the higher it is in the subtyping relation. As an example, we could also have specialized the power class by specifying that the op fields holds a reference to a concret object, as illustrated in Figure 4. The program can be simplified as before, with the exception that the unique object specified in the declaration of op has to be used when invoking the apply method. In the current implementation of GOO, code is generated at run time, and the address of the object is simply residualized in the program code. There are many other ways of dealing with object values during specialization; see next section for details. By providing a concrete object instance, specialization of the method can manipulate the object and therefore perform further optimizations; for example, the object can be compared to other objects. I have implemented a minimal version of GOO that has been used to automatically perform the program generation illustrated in this section (whereas the example of Section 4 is not yet supported by my implementation). The implementation has been done as an interpreter written in SML/NJ [13]; currently all code generation is done at runtime as the program is being interpreted. GOO is strongly inspired by ongoing research in extensions to the Beta language, and the syntax that I currently use is perhaps most precisely described as Beta syntax with Haskell-style function declarations; for this reason, in this paper I use a manually pretty-printed syntax that more closely resembles Java. 4

5 User code: class MulPowerAlt extends Power { op:: new Mul(); Compiler-generated code: class MulPowerAlt extends Power { op:: new Mul(); int result = 1; int n = this.exp; while(n>0) { n = n-1; // assuming address stored in op is 0x02 result = 0x02.Mul::apply(result,base); return result; Optimized, compiler-generated code: see Figure 3. Figure 4: Specializing the power program using an object instance 3 GOO semantics, types and challenges Giving a complete description of the GOO semantics is of course out of the scope of this position paper, but I summarize the specialization process and the execution semantics. As for a type system, GOO currently does not have one, but I will discuss some of the issues in creating a type system. Last, I have a few comments on making GOO a more realistic language. 3.1 GOO semantics A GOO program consists of a set of classes and a main statement. When the program is interpreted, each class is processed in sequence, and any methods that are not inherited from the superclass (e.g., not overridden) are specialized according to the type information for the fields. A method is specialized using a mix of standard on-line specialization techniques for imperative languages [12] and techinques from existing work on off-line automatic program specialization for object-oriented languages adapted to work in an on-line fashion. Standard on-line techniques allow specialization for values stored in local variables. In addition, known type information (including concrete values) for fields is propagated throughout the method using the same mechanism. The immutability of the type declarations simplifies the process since no side-effects on objects occur during specialization. (Specializing for the values provided in the constructor, similarly to instantiation-time specialization [14], is not done, since it would leave the user with no place to specify values for which specialization should not take place, and would furthermore not have the same immutability properties.) Briefly, the transformations performed by specialization are as follows: known values from object fields are constant-propagated throughout the program, virtual dispatches are eliminated when the type of the receiver object is known, and any imperative computations that depend only on known values are reduced (conditionals with known tests are eliminated, loops with known tests are unrolled, etc.). 5

6 New specialized methods are generated for a virtual dispatch when the self or any of the arguments are known. Speculative evaluation of virtual dispatches can also be supported by allowing virtual prefixes [7, 11], as described in the appendix. During program execution, operations on objects are completely standard: field references and method invocations are performed as expected. The type declarations can impose strong restrictions on what values can be stored in a field and passed as arguments to methods. A field that has been specified equal to a given object can only be assigned this object. Similarly, a method parameter that has an object instance as its type can only be called with this object as an argument (see the appendix for details). 3.2 GOO type system Type checking a GOO program is (at least to some extent) done by the specialization process, which also means that type checking is not guaranteed to terminate, since arbitrary computations can be performed during the specialization process. From a typechecking point of view, GOO needs both virtual prefixes and covariant types for fields and method parameters, which is known to be difficult [11]. It remains unclear whether a type checking process driven by a specializer can statically type check such programs, or whether a more traditional type checker is needed as a second pass to ensure static typing. An interesting extension would to be let the GOO type system include a special kind of type modifier to represent something in between a traditional type and a traditional value, e.g. the type known int is a subtype of int, and any concrete number is a subtype of known int. We can then enforce that for a class to be instantiable, any known type inherited from the superclass must be specified as a concrete value. Thus, fields with a known type behave similarly to abstract methods. Such a known type could be used to specify e.g. that a field of type integer has to be assigned a concrete value in a subclass for the class to be instantiable. Propagating the known type throughout the class definition corresponds to bindingtime analysis in off-line specialization, and supplying a concrete value then results in the class being specialized. Based on a class annotated with known types, an optimizing implementation of GOO could predetermine all specialization actions, to make run-time code-generation highly efficient [4]. Specialization remains less predictable than template metaprogramming, even if the simplified specialization mechanism in GOO gives fairly predictable results (e.g., access to a field for type which information was specified always returns a known value, since type information is immutable) [15]. To improve predictability, type assertions could be added, so that at key points in the program it can be verified that a variable contains at least a known value. 3.3 Realistic GOO The GOO language as presented in this paper (1) generates possibly redundant specialized methods for every subclass, (2) residualizes object pointers inside compiled code, and (3) relies heavily on compiler optimizations such as inlining for an efficient result. Let me address these problems in turn. Code explosion: A key observation to reduce the number of methods generated is that a program which terminates in standard GOO also terminates if no methods are generated at run-time. Thus, methods could be generated dynamically based on profile information to optimize program hotspots, or method generation could be statically controlled by programmer annotations. 6

7 class Counter { CounterType:< integral; counter, increment: CounterType; filter: Filter; CounterType get_counter() { return this.counter; void inc() { this.counter = this.counter+this.increment; this.counter = this.filter.apply(this.counter); class Filter { abstract int apply(i: int); class Id extends Filter { int apply(i: int) { return i; class Wrap extends Filter { CounterType:< integral; bound: CounterType; CounterType apply(x: CounterType) { if(x>this.bound) return 0 else return x; Figure 5: The basic counter example in GOO Residualized pointers: The standard solution to avoid residualizing object pointers is use-sensitivity [9], which instead residualizes the program parts needed to pass the value to its destination. However, I am currently considering a alternative solution based on residualization of the run-time object structure of the program as code that can recreate the structure, but block structure is a complicating factor. Compiler optimization dependency: In a dynamic compilation system, the optimizations needed by GOO are best left to the compiler. I am strongly considering an execution model where Java code is generated by the GOO system, which would allow existing dynamic compilers for Java to be used. In a static system, a dedicated inliner and optimizer would probably need to be integrated into the GOO specialization mechanism. Naturally, there are many other problems as well, but these are the most significant issues that I ve run into so far, apart from speculative specialization of virtual dispatches which is discussed in the appendix. 4 Real generative programming: a counter At last year s ECOOP WGP, the counter example was used frequently to illustrate generative programming; in this example, a counter of integral type that can reset at a given limit is encapsulated inside an object. The counter example can be written in GOO as well, as illustrated in Figure 5. The class Counter contains a type variable for the counter type CounterType which is declared to be the same type as or a subtype of the type integral (I assume a common supertype integral for int, short etc.). In addition, Counter contains fields for the counter value, an increment, and an object that filters the counter value at each increment. Filters 7

8 User code: class Simple100Counter extends Counter { CounterType:< int; increment:: 1; filter:: Wrap_100; class Wrap_100 extends Wrap { CounterType:< integral; bound:: 100; Optimized, compiler-generated code: class Simple100Counter extends Counter {... void inc() { this.counter = this.counter+1; if( this.counter>100 ) this.counter = 0; Figure 6: Generating a counter implementation [manually generated] can either be the identity (i.e., no filtering) or a filter that wraps at a given bound (i.e., resets the counter). To generate a specific implementation of the counter, we use the class Simple- 100Counter shown at the top of Figure 6. This class specifies the counter type to be int, the increment to be 1, and the filter to be one that resets at a fixed bound. In the generated Simple100Counter class, the inc operation has been specialized to increment the counter by one and wrap at 100, as is shown in the optimized version. The versatile nature of GOO is illustrated by the fact that we can freely choose any subset of configuration parameters as fixed, and leave the rest as standard fields that can be modified dynamically. As a next step in the development of GOO, I am experimenting with more complex generative programming examples, such as lists and matrices [5], and in addition more examples from automatic program specialization for object-oriented languages. An obvious improvement to the specialization techniques presented here includes object inlining, where non-escaping, partially known objects are eliminated in compiled classes [14]. A Some technical details In this appendix I discuss some technical details related to the use of placeholder classes, specialization for the value of a method parameter, and speculative evaluation of virtual dispatches. A placeholder class is needed when subclassing introduces specialized methods in another class. As an example, consider the two classes X and Add: class X { a: Add; i: int; int f() { return a.add(this.i); class Add { j: int; int add(i: int) { return i+this.j; Specializing the X class with a specific value of i implies specializing the add method of Add. This method has to be placed somewhere, which has to be indicated by the programmer, with a place-holder class, as follows: class X extends X { a: Add_spec; i:: 1; 8

9 class Add_spec extends Add; Here, Add spec is a placeholder class, which can be filled in by the compiler as needed. The result is the following program: class X extends X { a: Add_spec; i:: 1; int f() { return a.add(1); class Add_spec extends Add { int add(i:: 1) { return 1+this.j; The compiler has added a specialized add method in the placeholder class. Without the use of placeholder classes, either specialized methods could not be added to other classes (which would be unacceptable), or there would be no programmer control of what new classes were created when specializing. In the latter case, if anewadd spec was automatically created, then the programmer could not ensure that only instances of this specific class was assigned to the field a. When specializing a method for a known argument value, not only is the method body specialized according to this value, but the signature of the method changes as well: the method can only be invoked if it is passed the exact value for which it was specialized. For this reason, one would typically create wrapper methods that invoke the specialized method with the correct argument. An interesting alternative would be to use a mechanism similar to predicate dispatching [2], but such an extension would perhaps be too complex. A virtual dispatch where the receiver object is unknown but some arguments are known can be specialized speculatively by generating new specialized methods for each of the potential receiver classes. With GOO, these specialized methods need to be placed in subclasses of the existing class hierarchy; in effect, a whole hierarchy of classes needs to be specialized together. Virtual prefixes allows a hierarchy of of classes nested inside a class to be specialized together in a subclass (for a recent example, see Ernst s family polymorphism [8]). I am currently working on extending GOO to use this mechanism to implement speculative evaluation of virtual dispatches. References [1] Luca Cardelli. Structural subtyping and the notion of power type. In Conference Record of the Fifteenth Annual ACM Symposium on Principles of Programming Languages, San Diego, pages 70 79, San Diego, California, [2] C. Chambers. Predicate classes. In Proceedings of the European Conference on Object-oriented Programming (ECOOP 93), volume 707 of Lecture Notes in Computer Science, pages , Kaiserstautern, Germany, July Springer-Verlag. [3] C. Chambers and D. Ungar. Customization: Optimizing compiler technology for SELF, A dynamically-typed object-oriented programming language. In Bruce Knobe, editor, Proceedings of the SIGPLAN 89 Conference on Programming Language Design and Implementation (PLDI 89), pages , Portland, OR, USA, June ACM Press. [4] C. Consel and F. Noël. A general approach for run-time specialization and its application to C. In Conference Record of the 23 rd Annual ACM SIGPLAN- SIGACT Symposium on Principles Of Programming Languages (POPL 96), pages , St. Petersburg Beach, FL, USA, January ACM Press. [5] Krzysztof Czarnecki and Ulrich W. Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison-Wesley,

10 [6] Proceedings of the European Conference on Object-oriented Programming (ECOOP 99), volume 1628 of Lecture Notes in Computer Science, Lisbon, Portugal, June Springer-Verlag. [7] Erik Ernst. Propagating class and method combination. In ECOOP 99 [6], pages [8] Erik Ernst. Family polymorphism. In Jørgen Lindskov Knudsen, editor, Proceedings of the 15th European Conference on Object-oriented Programming (ECOOP 2001), volume 2072 of Lecture Notes in Computer Science, pages Springer-Verlag, June [9] L. Hornof, J. Noyé, and C. Consel. Effective specialization of realistic programs via use sensitivity. In P. Van Hentenryck, editor, Proceedings of the Fourth International Symposium on Static Analysis (SAS 97), volume 1302 of Lecture Notes in Computer Science, pages , Paris, France, September Springer-Verlag. [10] O.L. Madsen, B. Møller-Pedersen, and K. Nygaard. Object-oriented programming in the Beta programming language. Addison-Wesley, Reading, MA, USA, [11] Ole Lehrmann Madsen and Birger Møller-Pedersen. Virtual classes: a powerful mechanism in object-oriented programming. In Conference proceedings on Object-oriented programming systems, languages and applications, pages , New Orleans, Louisiana, United States, [12] U. Meyer. Techniques for partial evaluation of imperative languages. In Partial Evaluation and Semantics-Based Program Manipulation (PEPM 91), pages , New Haven, CT, USA, September ACM SIGPLAN Notices, 26(9). [13] R. Milner, M. Tofte, R. Harper, and D. MacQueen. The Definition of Standard ML (Revised). The MIT Press, [14] U.P. Schultz. Object-Oriented Software Engineering Using Partial Evaluation. PhD thesis, University of Rennes I, Rennes, France, December [15] U.P. Schultz. Object-oriented program specialization: Aspects into aspects or maybe not?, June Position paper at Workshop for Generative Programming, ECOOP [16] U.P. Schultz. Partial evaluation for class-based object-oriented languages. In O. Danvy and A. Filinski, editors, Symposium on Programs as Data Objects II, volume 2053 of Lecture Notes in Computer Science, pages , Aarhus, Denmark, May [17] U.P. Schultz and C. Consel. Automatic program specialization for Java. DAIMI Technical Report PB-551, DAIMI, University of Aarhus, December [18] U.P. Schultz, J. Lawall, C. Consel, and G. Muller. Towards automatic specialization of Java programs. In ECOOP 99 [6], pages [19] T.L. Veldhuizen. C++ templates as partial evaluation. In ACM SIGPLAN Workshop on Partial Evaluation and Semantics-Based Program Manipulation (PEPM 98), pages 13 18, San Antonio, TX, USA, January ACM Press. 10