Speeding up the Meta-level Processing of Java Through Partial. Evaluation.

Transcription

1 Speeding up the Meta-level Processing of Java Through Partial Evaluation Mathias Braux Ecole des Mines de Nantes La Chantrerie - 4, rue Alfred Kastler - B.P Nantes Cedex 3, France Abstract Run-time features like reection in object-oriented languages decrease application performance. In order to reconcile exibility and performance, we adapt the standard partial evaluation process to deal with Java reection API. This paper present away to evaluate at compile time the meta-object computations that normally take place at run time. A classication of the Java reective methods allows the partial evaluation process when to start and end. 1 Introduction Many useful features of object-oriented languages which improve sofware exibility, like inheritance or polymorphism, are run-time features. This means that they rely on some mechanisms ensuring late binding e.g., a reference to a class instance, or a table for virtual functions implies one more level to evaluate. In the same way, reective features imply a level of indirection which lowers performance. However, to recover software performance, some of run-time bindings can be computed at compile time. For example, the run-time binding of a class (i.e., polymorphism) can be computed at compile time with a class hierarchy analysis process (see for instance [6]). Also, useless code can be removed at compile time from the program through program slicing [18, 17]. Partial evaluation [2, 11] is another compile-time technique. When part of a program input is known at compile time, partial evaluation propagetes this information and produce a residualized program which wil deal, at run time, with the rest of the input. Good results have been shown when applying this technique to signicant applications (RPC protocol [15], Fast Fourrier Transformation [8]...). However, partial evaluation had been mainly used to deal with languages that do not separate well the meta-level from the baselevel (C, logic programming language like Prolog, fonctional programming languages like Lisp or Scheme). Therefore, nowadays, partial evaluation techniques are also used to compile away the meta-object code of a program (by propagating invariant properties through this code) [4, 14]. This paper focuses on partial evaluation for the re- ective part of Java. The reection features of Java are described in Section 2 and an example is given. We present a useful taxonomy of the reection API which will enable partial evaluation. In Section 3, we introduce the standard partial evaluation and we present an extended version of such a process to optimize the reection API of Java. In Section 4, we address related work and we conclude in Section 5. 2 The Reection API of Java Java provides a reection API which reies the basic structural elements of its model, classes, constructors, methods, elds... into objects of type Class, Constructor, Method, Field.... Since these objects

2 are objects used to describe objects, they are called meta-objects [12]. When a meta-object receives a message, the computation resulting from the invocation of the method (a meta-level method) is called a meta-level computation. The other computations are located at the base-level and deal with base-objects. 2.1 A Toy Example The following example returns a string that concatenates the class name of an object and the name of the rst method held in its dictionary. The packagename argument represents a the name of a package to be added at the beginning of the string. public String getinfo(object obj, String packagename) { Method[] setofmethods = obj.getclass().getmethods(); String theresult = new String(); theresult=theresult.concat(packagename); theresult=theresult.concat(obj.getclass().getname()); theresult=theresult.concat(setofmethods[0].getname()); return(theresult); } Two kinds of objects are involved in this code: the base-objects (obj, theresult and packagename) and the meta-objects (setofmethods). 2.2 The Reective Features The Java API provides reective features to allow introspection of Java code. We believe that the reection API (cf Java documentation) is dierent from the other Java APIs. Many meta-level computations are independent from the base-level object state. The result of these meta-level computations depends only on the base-object types (i.e., classes). Figure 1 gives an example which computes the expression X. This expression returns the rst method name of the baseobject obj (which is a RemoteObject instance). The arrow run-time1 is a method call which goesuptothe meta-level and returns the reied class of obj. The arrow run-time2 is a second kind of method which works at the meta-level and returns the entire method dictionary of obj. The arrow run-time3 corresponds to a method which ends the meta-level computation, it goes down to the base-level and returns the name of the rst method of a RemoteObject (i.e. Object Clone()). Therefore, once the class of an object is xed, the result of the meta-level method can be computed at compile time (cf. arrow compile-time on Figure 1). We have identied three important categories of such meta-level methods. All of these methods can be subject to partial evalutation. 1. The rst category contains methods which go up to the meta-level. There is a single such method: Object.getClass(), which returns the class of the receiver. 2. The second category contains methods whose computations take place within the meta-level (i.e. they work on meta-objects). They return a meta-object (for example getmethods() returns an array of meta-objects Method). This category includes Method[] Class.getMethods(), Constructor[] Class.getConstructors(), Field[] Class.getFields(), Class[] Class.getInterfaces(), Class Class.getSuperclass(), Class[] Class.getClasses(). 3. The third category also work on meta-objects and contains methods which return a base-object (String, primitive type wrappers and for sake of simplicity, we include primitive types in the term "base-object") and terminate the metacomputation by going down back to the baselevel. Here we nd tostring(), getname(), hashcode(), getmodifiers(), for each of the classes Field, Method, Constructor and Class class. We nd also int getmodiers() from Class, Method and Field classes. Those method calls are performed at run-time. In order to improve software performance, we want to perform them at compile time. The classication given above allows the partial evaluation process to know when a meta-computation starts (a method of the rst category is invoked) and when it stops (a method of the third category is invoked). 3 Partial Evaluation Partial evaluation [2, 11] is a source to source transformation technique whose aim is to improve software

3 Meta-object Level C Run-time 2 M Method M = C.getMethods() String S = M[0].getName() Run-time evaluation of X Run-time 1 Class C = obj.getclass() RemoteObject obj Run-time 3 X="Object Clone()" X=obj.getClass().getMethods()[0].getName() Base-level Compile-time evaluation of X Base-level Compile-time Partial evaluation X="Object Clone()" Meta-level object Base-level object Figure 1: Meta-object level compile-time optimization performance. From a generic program and part of the program input (called the static part of the input), partial evaluation produces a specialized program which only needs to deal with the remaining part of the input (the dynamic part of the input) at run-time. Partial evaluation can be applied in two ways: on-line or o-line. On-line partial evaluation directly propagates the static input through the program. Alternatively, an o-line partial evaluator rst deals with abstract values. There are basically two abstract values, "static" for static input and "dynamic" for dynamic input. A Binding-time analysis [10] propagates this information through the program. It is only in a second phase that the program is actually specialized using concrete values. The binding-time analysis factorizes a part of the whole process. When the same program must be specialized several times with respect to multiple static input, some redondant computation are avoided. The basic partial evaluation of the example given in Section 2 is described in Section 3.1. However, in this article, we focus on the meta-level method calls. Egon Borger [1] split Java semantic in several parts. Those we are interested in are the standard imperative core semantics JAVA I and the object core semantics JAVA C and JAVA O.JAVA I denes a domain for variables and both JAVA C and JAVA O dene domains for object and their classes (i.e. their types). Standard partial evaluation techniques such as the ones used in Tempo [5] can straightforwardly deals with JAVA I. Here, we are interested in extending them in order to deal with both JAVA C (classes) and JAVA O (objects) semantic parts. In this way, we extend a standard partial evaluator to propagate both variable values and variable type. The two following examples are processed by an online partial evaluator. 3.1 An Example of Partial Evaluation Given the method getinfo() of Section 2.1, and assuming it is only used with a particular context (for example, packagename = "java.lang: "), the variable packagename becomes static in the whole code. Then, getinfo() can be transformed through standard partial evaluation techniques into a faster residual method which we call R1 getinfo(object obj):

4 public String R1_getInfo(Object obj) { Method[] setofmethods = obj.getclass().getmethods(); String theresult = new String(); theresult=theresult.concat("the class is : "); // CHANGED theresult=theresult.concat(obj.getclass().getname()); theresult=theresult.concat(setofmethods[0].getname()); return(theresult); } In the previous example, the value of variable packagename has been "inlined" in the method body. The late binding of the variable has been removed, making the method faster. This partial evaluation process only deals with base-object states. Let us consider its extension to base-object types. 3.2 Partial Evaluation at Meta-Level A part of meta-level computations deals with another kind of invariant: classes. Objects references cannot have a textual representation, and therefore, cannot be manipulated like primitive types. The results of meta-level operations can only be usefully computed at compile time when the results of those methods can be represented textually (e.g., when applied to a known class, the getname() method returns a character string). Each method that belongs to the classication (cf. Section 2.2) will be evaluated at compile time with respect to its category. Denition The partial evaluation of a metacomputation starts with the invocation of a method from the rst category, proceeds while it encounters methods from the second category (while keeping the results in a special store) and ends when returning from the rst invocation of a method from the third category. At this stage, the result of the last method is a base-object. Then, the process can replace the evaluated expression with this base-object value. Example We illustrate the specialization process with an on-line technique and we reuse the previous example with another kind of context. The context only include base-object types. For example, we assume that the type of obj is a RemoteObject (package RMI in Java API) and that the rst method in its dictionary is Object clone(). The R1 getinfo() method can be transformed into a faster residual method (which we call R2 getinfo()): public String R2_getInfo() { String theresult = new String(); theresult=theresult.concat("the class is : "); theresult=theresult.concat("remoteobject"); // CHANGED theresult=theresult.concat("clone()"); // CHANGED return(theresult); } This example is automatically computed by our transformation framework that is under construction (cf. Section 5). The rst line of the method body is evaluated at compile time and the set of the public methods of obj is stored. The expression obj.getclass().getname() is partially evaluated in the above context and returns the string "RemoteObject". Then, the special store is used to statically compute the expression setofmethods[0].getname() (the computation returns the string "clone()"). A dead code elimination process discard the variable setofmethods and Object Obj declarations (since they are no more useful). The speedup of such specialization for 1000 invocations at the method getinfo() is closed to 7 times (on a SPARC station 5 running Java jdk1.1.6). In a larger frame, applications using meta-object protocol are good applicants to such a partial evaluation process. Therefore, we think that "extended partial evaluation" should be taken into account. At the moment, we only deal with meta-level methods that do not have any side eect on the base-level, and for which the base-level does not also have any side eect on the meta-level. For example, we do not handle the forname(string classname) method since "classname" is a base variable which inuences meta-level computations. 4 Related Work Three main directions for implementing ecient reective languages exist [4]. They all try to anticipate the binding time of meta computations at compile time. The Currying technique (applied to CLOS [12]), partial evaluation for meta-object protocol [14] and the specialization technique of compile-time meta-object protocol (applied to OpenC++ [3]) do not t well with the Java meta-level model. The Currying technique and the specialization technique of compile-time meta-object protocol are both

5 need to process their program division (separation of meta-object code in a static part and a dynamic part) by hand. Partial evaluation directly compute a residual program of an meta-object code, according to an base-object code. The Currying technique uses lambda-expressions to factorize recurrent metaclass method calls (a part of the call context is usually constant). Then, the result of the lambda-expression can be stored in order to avoid some useless computations. This transformation is used to directly retrieve computation results via a cache improving the meta-object protocol performance. This process is closed to data-specilization [13]. The specialization technique of compile-time metaobject protocol do not use a cache neither a lambdaexpression but factorize by hand static part of a metaobject code, and therefore, is closed to a partial evaluation process by hand). The third method uses partial evaluation. Partial evaluation can compute a specialized meta-level program according to a base-level code. This ts the Futamura projection [7] but cannot be applied as Java is not interpreted but compiled to byte-code. This technique is used [14] to partial evaluate a meta-level interpreter for ABCL/R3 (a concurrent reective language) but requires to modify the standard meta-object protocol. In Java, no meta-object protocol source code is provided, except for some extensions like MetaJava [9] or OpenJava (the OpenC++ Java version). These three directions cannot be applied. We have therefore proposed a partial evaluation process which propagates type values through the meta-level. 5 Conclusion and Future Works This paper presents a method for compiling-away a part of meta-level computation of a program. These meta-level computations should be isolated in order to specialize it. A partial evaluator which propagates type values is required because the meta-level methods are not processed like the others in Java. We must therefore deal with these methods in another way. We have given an example that could have been produced by an on-line partial evaluator taking types into account and for which, speed-up is promising. In order to completely validate our work, an application for several transformation processes is currently being developed. In addition, this transformation of the reective part of a program can be a prerequisite to run other kinds of specialization (for example, another partial evaluation or an object slice [16, 17]... ). We are currently interested in extending our approach to methods with side-eects in order to compose variable value propagation and type value propagation. 6 Acknowledgments Special thanks to Jacques Noye for many fruitful discussions. Thanks to Thomas Ledoux, Noury Bouraqadi and Gilles Trombettoni for their comments on a draft of this paper. References [1] E. Borger and W. Schulte. Programmer friendly modular denition of the semantics of Java. In J. Alves-Foss, editor, Formal Syntax and Semantics of Java, Lecture Notes in Computer Science. Springer-Verlag, [2] Charles Consel and Olivier Danvy. Tutorial Notes on Partial Evaluation. ACM Symposium on Principles of Programming Languages, pages 493{501, [3] Shigeru Chiba. A Metaobject Protocol for C++. In OOPSLA'95, Tenth Annual Conference on Object-Oriented Programming Systems, Languages, and Applications, pages 285{299, Austin, Texas, USA, October ACM Press. ACM SIGPLAN Notices, 30(9). [4] Shigeru Chiba. Implementing Techniques for Ecient Reective Languages. Technical report, Departement of Information Science, University of Tokyo, June [5] C. Consel, L. Hornof, J. Lawall, R. Marlet, G. Muller, J. Noye, S. Thibault, and N. Volanschi.

6 Tempo: Specializing systems applications and beyond. In ACM Computing Surveys,Symposium on Partial Evaluation, [6] Jerey Dean, David Grove, and Craig Chambers. Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis. In ECOOP'95 - Object-Oriented Programming - 9th European Conference, volume 707, Aarhus, Denmark, August Springer-Verlag. [7] Y. Futamura. Partial Computation of Programs. In RMIS Symposia on Software Science and Engineering, number 147 in LNCS, page 135, [8] Robert Gluck, Ryo Nakashige, and Robert Zochling. Binding-time analysis applied to mathematical algorithms. In J. Dolezal and J. Fidler, editors, System Modelling and Optimization, pages 137{146. Chapman & Hall, [9] Michael Golm and Jurgen Kleinoder. MetaJava - A Plateform for Adaptable Operating-System Mechanisms. In ECOOP 97 Workshop on Reective Real-time Object-Oriented Programming and Systems, June [10] Luke Hornof and Jacques Noye. Accurate Binding-Time Analysis For Imperative Languages: Flow, Context, and Return Sensitivity. In ACM SIGPLAN Symposium on Partial Evaluation and Semantic-Based Program Manipulation, June [14] Hidehiko Masuhara and Akinori Yonezawa. Design and Partial Evaluation of Meta-objects for a Concurrent Reective Language. In ECOOP'98 - Object-Oriented Programming - 12th European Conference, volume 1445, pages 418{439, Brussels, Belgium, July Springer-Verlag. [15] Gilles Muller, Eugen-Nicolae Volanschi, and Renaud Marlet. Scaling up Partial Evaluation for Optimizing the Sun RPC Protocol. In Symposium on Partial Evaluation and Semantic-Based Program Manipulation, Amsterdam, June ACM SIGPLAN. [16] Thomas Reps. Program Analysis via Graph Reachability. In J. Maluszynski, editor, ILPS '97: International Logic Programming Symposium, Port Jeerson, NY, pages 5{19, Cambridge, MA, October The M.I.T. Press. [17] Thomas Reps and Todd Turnidge. Program Specialization via Program Slicing. In O. Danvy, R. Glueck, and P. Thiemann, editors, Lecture Notes in Computer Science, volume 1110, pages 409{429, Springer-Verlag, New York, NY, [18] Frank Tip. A survey of program Slicing Techniques. Technical report, Computer center of Wiskunde dpt of software technologie, [11] Neil D. Jones, Carsten K. Gomard, and Peter Sestoft. Partial Evaluation and Automatic Program Generation. Prentice Hall, International series in computer science, [12] Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow. The Art of the Metaobject Protocol. Cambridge, MIT Press, [13] T.B. Knoblock and E. Ruf. Data specialization. In Proceedings of the ACM SIGPLAN '96 Conference on Programming Language Design and Implementation, pages 215{225. ACM SIGPLAN Notices, 31(5), May 1996.