Jumbo: run-time code generation for java and its ... - IEEE Xplore

Jumbo: Run-time Code Generation for Java and Its ApplicationsSam Kamin ∗ , Lars Clausen, Ava JarvisComputer Science DepartmentUniversity of Illinois at Urbana-ChampaignUrbana, IL 61801{s-kamin,lrclause,ajar}@uiuc.eduAbstractRun-time code generation is a well-known technique forimproving the efficiency of programs by exploiting dynamicinformation. Unfortunately, the difficulty of constructingrun-time code-generators has hampered their widespreaduse. We describe Jumbo, a tool for easily creating run-timecode generators for Java. Jumbo is a compiler for a twolevelversion of Java, where programs can contain quotedcode fragments. The Jumbo API allows the code fragmentsto be combined at run-time and then executed. We illustrateJumbo with several examples that show significant speedupsover similar code written in plain Java, and argue furtherthat Jumbo is a generalized software component system.Keywords: run-time code generation, Java1 IntroductionJumbo is a dynamic compiler for Java capable of pullingtogether fragments of Java code — down to the level of singleexpressions or statements — into a single program andcompiling the combined program at run-time. Jumbo doesnot simply build the program as text and invoke the Javacompiler from the running program. Instead, the compileris structured in such a way that fragments can be separatelycompiled to an intermediate form from which the full programcan be assembled without reinvoking the compiler. Inother words, Jumbo builds run-time code generators.This structure allows for significant flexibility in the programgenerators Jumbo can build. Furthermore, since theprogram generators are binaries (that is, Java class files)and produce binaries, with no separate invocation of thecompiler, Jumbo passes the “deployability” test for components.From this point of view, Jumbo can be seen as a∗ Partial support for the first and second authors was received from NSFunder grant CCR-9619644.component-constructing tool of great generality — greaterthan traditional component systems that operate at the levelof whole methods or classes. Jumbo components can bethought of as “run-time macros.”In this paper, we introduce Jumbo and give several examplesof its use. To a great extent, using Jumbo “feels”like creating strings that look like programs and then compilingthem. Conceptually, the model is very simple. Insome examples, complex interactions between componentand client make for an inherent complexity that Jumbo cannoteliminate; however, the programmer’s focus is alwayson the question “What should the generated program looklike?”, and this makes Jumbo straightforward to use.The next section gives an overview of the Jumbo system.In Section 3, we present two examples of the use of Jumbo.References to related work and conclusions are presented inthe final sections.2 The Jumbo SystemJumbo is a “compiler API,” consisting of about a dozenclasses, the most important of which is Code. Code containsa number of static methods similar to these examples:static Code binop (int, Code, Code)static Code ifThenElse (Code, Code, Code)static Code returnVal (Code)These methods correspond to abstract syntax operations,acting upon and producing values of type Code. WhenusingJumbo, it is not misleading to think of Code as containingabstract syntax trees, or even strings; however, Code isneither of these things, but is instead a partially compiledvalue. Programmers will rarely use these AST operationsdirectly, as a special quotation syntax is provided to producecalls to these operations. We will show examples ofthe quotation syntax later in this section.In addition, the Code class provides the following twoinstance methods:1Proceedings of the International Symposium on Code Generation and Optimization (CGO’03)0-7695-1913-X/03 $17.00 © 2003 IEEE

void generate ();Object create (String classname);}outputResult(p);The generate() method converts a Code value intoJVM code and writes the corresponding class files; theCode value must correspond to a class or list of classes.create() calls generate() and then loads the namedclass and returns a new object of that class. (In the currentversion of Jumbo, due to our reliance on the Classmethod newInstance(), no arguments can be passed tothe constructor.)The basic idea behind Jumbo is compositional compilation[6]. The crucial point is that the abstract syntax operationsof the Jumbo API are the compiler. Unlike an ordinarycompiler in which the syntax tree is a passive data structureupon which the compiler operates, the Jumbo operators aregenuine functions that perform compilation. This is calleda compositional compiler because the compilation of eachlanguage construct is a function only of the compilation ofits sub-constructs — a very different structure from conventionalcompilers. The advantage is that any particular pieceof syntax can be easily abstracted from and filled in at a latertime.The idea of compositional compilation is widely applicableto different languages and target architectures. In [6],we used a variant of Java and targeted SPARC machine language.Some languages and target architectures are muchmore difficult to compile compositionally than others, andtradeoffs in code quality must be made. The structure ofJava and its implementation by an abstract machine are particularlywell suited to our approach, and Jumbo producesvirtually the same code as the javac compiler. Only innerclasses, being especially difficult to handle, are not yetimplemented in Jumbo.2.1 Using code generatorsIn discussing Jumbo programs, we often refer to the supplierof the code generator as the server, andtheuserofthe supplied code generator as the client. Following thismetaphor, we also sometimes refer to Jumbo programs ascomponents.The following code is a typical Jumbo client whichuses a vector dot-product generator supplied by a server.Dot is an interface containing the method doubledot(double[]).double[] vec1 = getInputVector();Code dotprodcode = codegenDot(vec1);Dot dotprod =(Dot)dotprodcode.create("DotProd");while (true) {double[] vec2 = getInputVector();double p = dotprod.dot(vec2);The server supplies codegenDot, a Jumbo methodwhose function is to produce a class that implementsthe Dot interface. We will show the definition ofcodegenDot shortly. As with any other library code,the client knows only the type, Code codegenDot(double[]), and purpose of the method. create canbe applied to the value returned by codegenDot to compilethe class (named DotProd) and return an instance ofthat class. Since that class does not exist at the time theclient code is compiled, we must use the Dot interface.In summary, the client uses the method codegenDotto produce a method that is specialized to multiply othervectors by the fixed vector vec1. Fixing one of the vectorsin a dot product calculation offers the potential to speed upthe calculation by using dynamic information. That informationincludes the length of the vector, which allows thedot product loop to be unrolled, and its values, which maybe exploited to gain efficiency — for example, by omittingmultiplications by zero or one.The pure Java alternative to the above would use a nongeneratingdot product routine, say dotprod:double[] vec1 = getInputVector();while (true) {double[] vec2 = getInputVector();double p = dotprod(vec1, vec2);outputResult(p);}where dotprod is the straightforward library method(omitted for brevity).The advantage of the dynamically compiled version isthat, in some cases, it may be much faster; the disadvantageis that, in other cases, it may be much slower due thecost of run-time compilation. Like any other programmingtool, Jumbo must be used judiciously. When appropriatelyapplied, Jumbo gives speed-ups that are hard to obtain byconventional means.2.2 Speed-upsA use of Jumbo involves three time-consuming stages:1. Loading the Jumbo API.2. Generating and loading the class file.3. Executing the generated code.In the DotProduct example, step 2 is performed whenvariable dotprodcode is assigned and then sent thecreate message. If the class file were created during onesession (by sending the generate message) and then used2Proceedings of the International Symposium on Code Generation and Optimization (CGO’03)0-7695-1913-X/03 $17.00 © 2003 IEEE

in a separate session, we would break step 2 into two parts,but for this example that is not necessary.Each of these timings is potentially of interest to theJumbo user. A single use of Jumbo, as in the current example,entails all three steps. Once the Jumbo API is loaded(or, speaking more speculatively, if it were built into thevirtual machine) step 2 represents the incremental cost ofgenerating new code dynamically. Step 3 gives the “bottomline”, the speed of the generated code — which should be,and is, substantially faster than plain Java code. Whetheror not using Jumbo saves time overall depends on how it isused.Note that there are two variables in the dot product computationthat affect the overall computational cost: the sizeof the vectors and the number of dot product computationsthat are performed. The cost of step 1is independent ofthese numbers, and the cost of step 2 depends only on thevector vec1. For the timings presented here, we usedrandomly-generated 100-element vectors of two kinds: nobias, and bias towards generating zeroes (sparse vectors).The results are given in Table 1. The dot product computationwas repeated a varying number of times (n), from 10to 1,000,000. For the Jumbo version, the code generationprocess (step 2) occurred just once in each run.All timings were produced on an unloaded 1.47GHzAthlon PC with 1GB of memory, running Linux kernel2.4.18. We used Sun’s Java SDK, version 1.3.1 (StandardEdition, Blackdown build). Times are in milliseconds, obtainedwith a microsecond timer routine.The results are easily summarized:• Step 1, the loading of the Jumbo API, took about 0.2seconds. For small numbers of iterations, this timedominates. Step 1takes about 15 times longer thanstep 2 (in the unbiased case).• Step 2, code generation, took about 14 milliseconds forthe unbiased vector and 6 milliseconds for the biasedvector. This is, in turn, about 300–700 times slowerthan a single dot product calculation. (See Table 1formore accurate numbers.) Note that the cost per dotproduct declines significantly as the number of iterationsrises because of the effect of run-time optimizationsin the Java run-time implementation. Thus, for10 iterations, the cost is about 19 µsec per iteration;for 1,000,000 iterations, the cost goes down to about.3 µsec per iteration. Since the cost of code generationremains constant, the ratio of code generation toexecution time rises sharply.• Step 3, execution time of the generated code for theunbiased case took from 19 µsec per dot product computationdown to about .3 µsec, as discussed above.For the biased case, these numbers were cut approximatelyin half, as would be expected.Random data Jumbo JavaLoad API 226.0 N/ACode gen. 14.3 N/ARun-time (n)10 0.19 0.16100 0.7 1.51000 5.6 19.610000 15.5 48.9100000 43.2 127.41000000 290.7 929.150% 0’s Jumbo JavaLoad API 228.0 N/ACode gen. 5.57 N/ARun-time (n)10 0.1 0.16100 0.4 1.51000 3.0 15.110000 8.3 39.8100000 24.3 120.21000000 151.0 925.8Table 1. Effect of dynamically compiling dotproduct routine. (Times in milliseconds.)• By comparison, the Java version does not pay the costsof steps 1and 2, but the dot product computation tookfrom 16 µsec to .9 µsec in both the unbiased and unbiasedcases, per iteration. (The biased case is slightlyfaster because floating-point multiplication by zero isfaster on this platform than multiplication by non-zerovalues.) Over time, the generated code in the unbiasedcase ran about three times faster per iteration thanthe Java code, and in the biased case, about five timesfaster.The “cross-over point” depends upon which parts of thecomputation are included. For a complete run, includingall three stages of Jumbo computation, the cross-over is atabout 400,000 iterations in the unbiased case, 300,000 in thebiased case. If the API is assumed to be preloaded — whichis to say, for all uses of Jumbo except the first — then thecross-over points are at about 1000 and 500 iterations forthe two cases.The results of this run show the potential for significantspeed-ups when the cost of loading and dynamic codegeneration is amortized over a sufficient number of uses.For the unbiased vectors, where the only benefits of Jumbocome from loop unrolling, the Jumbo version is eventuallyover three times as fast as Java; for the biased vector, theimprovement factor is about five.3Proceedings of the International Symposium on Code Generation and Optimization (CGO’03)0-7695-1913-X/03 $17.00 © 2003 IEEE

We are currently investigating methods of decreasingrun-time compilation time, and we expect great improvementsby applying partial evaluation techniques. Furthermore,Jumbo can be used statically as well as dynamically,and in some cases (as in the example in Section 3.1) this isquite appropriate. In that case, the run-time seen by the userwould be that shown in the last column.2.3 Writing code generatorsSomeone has to write the code generators, and Jumbois easy to use in this respect. Component writers must usethe Jumbo compiler (unlike in the previous section, wherethe client only needed the Jumbo API and could have usedany Java compiler). The Jumbo compiler processes a “twolevel”version of Java to produce code generators, using aquote/anti-quote syntax similar to that of MetaML [10].A fragment of Java code within brackets $< and >$ representsa value of type Code:Code C = $< class CodeExampleimplements InterfaceType {... } >$;InterfaceType obj =(InterfaceType)C.create("CodeExample");/* ... use obj ... */The quotation syntax works much like ordinary string quotation,except that the result is a value of type Coderather than String. Java type-checking requires thatwe use an interface InterfaceType, since the classCodeExample does not exist at the time this code fragmentis compiled. (The argument to create is redundantin this case, but required because the Code value may, ingeneral, contain more than once class definition.)The Jumbo compiler is used to compile the code withinquotes. The only restriction on such quoted code is that innerclasses, not yet implemented in Jumbo, cannot be used.In our examples, we sometimes use inner classes, but neverinside quotes.Within a quoted Java fragment, values of type Code canbe “spliced,” using the anti-quotation syntax‘syntax-category(Java code fragment)The entire anti-quoted section is replaced, for parsing purposes,by a generic fragment of syntactic type syntaxcategory;the only reason we require the syntax category tobe present is to allow for parsing of the surrounding code.For example, we can writeCode addxy = $< x+y >$;Code assignz = $< z = x*5; >$;Code example =$< class CodeExampleCategoryExprStmtNameTypeCaseMethodFieldBodyCharIntFloatLongDoubleBoolStringExpression value expected (Type)Expressions (Code)Statements (Code)Identifiers (String) (Default category)Types (Type)List of case branches (MonoList of Code values)Method declaration (Code)Field declaration (Code)List of class members (MonoList of Code values)Character constant (char)Integer constant (int)Float constant (float)Long constant (long)Double constant (double)Boolean constant (boolean)String constant (String)Table 2. Syntactic categories for antiquotationimplements InterfaceType {... ‘Expr(addxy) ... ‘Stmt(assignz) ...} >$;InterfaceType obj =(InterfaceType)C.create("CodeExample");/* ... use obj ... */The anti-quoted expressions ‘Expr(addxy) and‘Stmt(assignz) are “holes” filled by the code inaddxy and assignz. As mentioned earlier, the casualuser can think of this as splicing strings into the stringexample; however, these values are not strings but ratherof type Code. 1The anti-quoted parts can be any Java expression of typeCode. If the method f has signature Code f(int), wecan write$< ... ‘Expr( f(3) ) ... >$At run-time, f(3) would be evaluated and the resultingCode value spliced into the surrounding Code value.Table 2 shows the syntactic categories available for antiquotations.For each case, the table shows the type of theexpression that must be given as an argument to the syntaxcategory. The examples above use syntax categories thattake arguments of type Code, Expr and Stmt. As thetable shows, there are some syntax categories that requiredifferent types of arguments:1 We insist on this perhaps seemingly pedantic distinction. In our view,it is a virtue of Jumbo that the programmer can think of these fragmentsas strings, because that is a simple model to understand; it is also a virtueof Jumbo that they are not strings, because this allows for a more efficient,non-source based implementation.4Proceedings of the International Symposium on Code Generation and Optimization (CGO’03)0-7695-1913-X/03 $17.00 © 2003 IEEE

• Name is a category used when the only syntacticallyvalid item is an identifier. Name would be used, forexample, to abstract the name of a class. This is the defaultcategory; when we write ‘ident with no syntaxcategory and no parentheses, ident mustbeavariableof type String.• Type is used wherever a type is required. In orderfor $< ‘Type(t) x, y; >$ to be a validdeclaration, t must be a Java expression of typeType. A value of type Type can be created by usingType.parseType(String jtype), wherejtype is a Java-style type. Type also defines constanttype values int type, float type etc. forthe primitive types.• The Case and Body categories require MonoListsof Code values. MonoList is a collection classinterface included in the Jumbo API and differsfrom Java’s List class primarily in that the addoperation has type MonoList add(Object) insteadof boolean add(Object); the functionalstyle add operator turns out to be more convenientfor our purposes. A quote of switch cases($$) returns aMonoList of Code values; all other quoted fragmentsreturn Code.• The last categories (Char, ..., String) musthavearguments of the corresponding types. (That is, expressionsof those exact types, not Code.) These allowJava values to be “reified,” i.e. turned into syntax thatcan be included in generated programs.There is only one Code type, but it covers a varietyof syntactic types. Intuitively, $$ should denote “aCode value of type Expr”, and $$ should denote“a Code value of type Stmt.” When we write, for instance,$$, we should insist that e evaluatesto a Code value of type Expr. However, we make nosuch distinctions and have only a single type, Code. Indiscourse,we often refer to a Code value “corresponding to”an expression or statement, etc. We do no type-checkingof generated code when we compile the program generator(as is done in MetaML); such type-checking is done whengenerate is called. generate and create may onlybe applied to a Code value corresponding to a class definitionor list of same.We have now completed our presentation of Jumbo andare able to present the definition of codegenDot. Wegainspeed-ups by unrolling the loop and using the fixed valuesof the static vector as constants, removing the iteration andarray lookup overhead. Additionally, we take advantage ofthe frequent presence of 0’s and 1’s in vectors by applyingsimple arithmetic equivalences of multiplication.The code used for Table 1follows:public static Dot codegenDot(double[] V1) {Code c =$$;return (Dot)c.create("DotProd");}public static Code makeSumCode(double[] V1,String V2) {Code sumcode = $$;for (int i = 0; i < V1.length; i++) {if (V1[i] == 1.0)sumcode = $$;else if (V1[i] != 0.0)sumcode = $$;}return sumcode;}If v1 were the array {5.2, 0.0, 2.4, 1.0}, thegenerated class would contain a method equivalent toreturn 0.0 + 5.2*vec2[0]+ 2.4*vec2[2] + vec2[3];Other static characteristics of the vector v1, such as repetitionsor symmetries, could be exploited as well.We have explained essentially all of the features ofJumbo: a “compilation API” with a parser that adds aquotation/anti-quotation feature. These conceptually simplefacilities are remarkably powerful, as illustrated in theremainder of this paper. Further examples can be found in[5, 6], which describe a predecessor of Jumbo.3 ExamplesIn this section, we give two examples that show the performancebenefit obtained using RTCG. The first exampleis a first-order method, which doesn’t require the client touse the Jumbo compiler, only the Jumbo API. The secondexample involves higher-order methods, where bothclients and component writers create code fragments usingthe Jumbo compiler.3.1 Generic data typesIn Java, most collection classes are generic in a trivialway: they contain only Objects. One disadvantage is thatprimitive values must be boxed in wrapper classes like like5Proceedings of the International Symposium on Code Generation and Optimization (CGO’03)0-7695-1913-X/03 $17.00 © 2003 IEEE

Integer and Character before being used in a collection.Boxing has a significant run-time cost due to extraobject creation. Yet these generic collection classes can beeasily transformed into non-generic classes: just replace thetype Object by the desired type of element, and recompile— in essence, the effect of using templates in C++.We can get the same benefit in Jumbo by supplying thetype name as a parameter to a program generator. For example,the Vector class in the Java library is a heavily usedcollection class, with operations like add and iterator.We created a non-generic collection class generator usingJumbo, which generates classes similar to the standardVector class. The generator provides three operations:static Type vector (String type);static Type iterator (String type);static Code newVector (String type);The vector and iterator methods are used to createthe names of the vector type corresponding to a particularnon-generic instance, and the type of its iterator. The argumentis the name of the component type. newVectorcreates an expression whose value is an object of the desiredcollection type. The non-generic class is created implicitlywhenever one of these operations is called, but is only createdonce.The implementation consists largely of a Java classplaced within quotations and abstracted on the names of theelement type and the collection type:Code C =$$;The only additional code, which is not shown, is the code toinsure that the desired collection class is generated exactlyonce.The timings shown in Table 3 were obtained by creatingvectors of various lengths (vlen) and then summing them:‘Type(vector("int")) v =‘Expr(newVector("int"));for (int i = 0; i < vlen; i++) {v.add(i);vlen vector(”int”) vector(”Object”)100 1 11000 2 210000 7 22100000 23 1321000000 186 976Table 3. Effect of dynamically compiled nongenericcollection class. (Times in milliseconds.)}int sum1 = 0;‘Type(iterator("int")) i;for (i = v.iterator();i.hasNext(); ) {sum1 += i.next();}For the Java column, we mimicked Java by creating ageneric class vector("Object") and using it as onewould an ordinary generic collection in Java.Table 3 shows only the execution times, since we assumethe various vector classes are created and compiled first, usinggenerate. Afterwards, they are ordinary class files,and can be used without further compilation. It will comeas no surprise to Java programmers that a vector of intsismuch more efficient than a vector of Integers.3.2 Loop unrollingThe full power of Jumbo can be employed only whenthe client has the Jumbo compiler and can write his owncode-producing methods. This provides for communicationbetween the component and client. Loop unrolling is onesuch situation: a loop unrolling component allows the clientto supply the body of a loop along with the bounds of theloop, and the component unrolls the loop as needed.Intuitively, loop unrolling is second order; the client suppliesthe body of the loop and the unrolling method repeatsit as necessary. However, supplying the body as a Codevalue does not allow the body to access the loop variable.The solution is for the body of the loop, supplied by theclient, to itself be a Code-producing function (more precisely,a function object). A component whose argument isa function is called a higher order component. Here, theclient passes an instance of the LoopIteration interface,in which the iteration method takes a code fragmentfor the iteration value and returns a code fragment forthe body, incorporating the iteration value:interface LoopIteration {6Proceedings of the International Symposium on Code Generation and Optimization (CGO’03)0-7695-1913-X/03 $17.00 © 2003 IEEE

Code iteration (Code i);}A loop unroller takes as arguments not only the numberof iterations and the loop body, but also the initial valueof the iteration variable, a loop increment, and the iterationvariable itself. Of these, only the iteration count and the incrementare constants; the initial value and the loop variableare expressions, and the loop body is a LoopIterationvalue.The simplest unroller is a complete unroller:public static Code unroll_all (Code i, // iteration variableCode init, // initial valueint incr, // increment (fixed value)int iterations, //iterations (fixed)LoopIteration F // loop body) {Code C = $< ; >$ ;for (int x=0; x$;C = $< ‘Stmt(C)‘Expr(i) = ‘Expr(init)+‘Int(iterations*incr);>$ ;return C;}The callunroll_all($$, $$, 1, 3,new LoopIteration () {public Code iteration (Code x) {return $$;}});produces code equivalent toSystem.out.print(0);System.out.print(1);System.out.print(2);i=3;Part of the unroller’s contract is to increment the index variableby the appropriate amount.This unrolling component can be applied to our initialexample, dotgen. However, full unrolling of the loopin dot can be highly disadvantageous. With an array ofsize 1000, the fully unrolled version runs approximatelyeight times slower than the original version. The reasonfor this difference in speed comes from one of two causes,or a combination thereof. The HotSpot run-time systemfor Java performs optimizations at run time selectively,with longer methods optimized much less aggressively thenshorter ones. Secondly, longer methods can result in costlymisses in the instruction cache. In any case, it has beenfrequently observed that long methods, though they executefewer instructions, can be slower than short ones.This suggests a compromise: partially unrolling theloops. In fact, this is the approach often used by traditionaloptimizing compilers. The following unroller has an additionalargument, the “block size,” i.e. the number of iterationsthat should be unfolded in each loop iteration.public static Code unroll_part (Code i, Code init, int incr,int iterations, LoopIteration F,int BlockSize // max loop size) {int loops = iterations/BlockSize,leftover = iterations%BlockSize;if (loops < 2) // 0 or 1 loops - unrollreturn unroll_all(i, init, incr,iterations, F);elsereturn$< for (‘Expr(i)=‘Expr(init);‘Expr(i) < ‘Expr(init)+ ‘Int(loops*BlockSize*incr); ){‘Stmt(unroll_all(i, i, incr,BlockSize, F))}‘Stmt(unroll_all(i, i, incr,leftover, F))>$;}When run on a vector of 1000 elements, the most efficientdot product computation (counting only run time, not codegeneration time, and repeating the dot product computation100,000 times) was achieved using a blocking factor of24. The execution speed was about 14% faster than no unrolling,and about ten times faster than complete unrolling.4 Related workSeveral researchers have noted that program generatorsmight be useful in ways that conventional components arenot. An example is Batory’s notion of components as layers[1]. In this view — greatly simplified — a component is acollection of classes whose superclasses are undetermined.From our point of view, then, a “layer” is a function froma list of superclass names to a list of classes. This is easyto implement in Jumbo (we simplify here by assuming thecomponent contains just one class):7Proceedings of the International Symposium on Code Generation and Optimization (CGO’03)0-7695-1913-X/03 $17.00 © 2003 IEEE

Code myComponent (String superclass) {return $< class myClassextends ‘superclass {...} >$;}Instantiating a layer means applying it to a particular classname:myComponent("MySuperClass").generate();Another example is [7], in which simple additions to classfiles are made automatically at load time (mainly to solveversion integration problems); again, this facility could beprovided by using Jumbo. Yet another is the work of Franzand Kistler [3], in which a compact representation of abstractsyntax trees is used as the medium of communicationof programs, instead of conventional binaries; compilationto machine code is performed at load time.Undoubtedly, these systems require support that goes beyondwhat Jumbo can offer and therefore need to be builtinto Java compilers and run-time systems in some ways.However, to a first order of approximation, these are justRTCG systems, and Jumbo provides a simple way to experimentwith such ideas.On a technical level, Jumbo’s closest relatives are varioustwo-level language systems, such as MetaML [10] and’C [2]. As compared with these, Jumbo is distinguishedby the simplicity of the programming model it provides.To a great extent, Jumbo programmers can think of theirprograms simply as strings. The systems cited above imposevarious restrictions that limit the programmer’s abilityto abstract on some parts of their programs (most notably,on type names). In Jumbo, context-sensitive checksare not done until the entire program is put together at codegenerationtime.MetaML [10] is a partial evaluation system with explicitstaging. Though superficially similar, MetaML and Jumboare quite different at the semantic level. MetaML is designedto be transparent to the programmer, in the sensethat the only result of omitting the staging information willbe slower execution. This transparency has an obvious advantage:the programmer is really programming in only onelanguage — the two-level annotations are just “pragmas”— so that writing correct programs is no more difficult thanin the base language. Its disadvantage is that, as mentionedabove, the available abstractions are limited to those alreadyavailable in the base language; programs cannot be parameterizedon type names or exception names, for instance.There is also a serious question of control of the specializationprocess which arises in all partial evaluation-basedsystems: the difficulty in arranging to have exactly the rightcode generated at run time. For example, in the sorting examplein [5], a certain code fragment is to be inlined onlyif a particular variable has a value within a given range; theMetaML programmer cannot make this decision explicit.JSpec [8] is a partial evaluation system for Java programs;the programmer indicates where and when specializationshould occur in a “specialization class” separatefrom the Java program itself. The comments just made withrespect to MetaML apply here as well.’C [2] and Cyclone [4] are systems that are similar toours in that they include a two-level notation to specify runtimecode generation. As mentioned above, these systemsimpose restrictions to insure that type-checking can be performed(mostly) by the compiler, that control flows into andout of generated code are known to the compiler, and soon. In Jumbo, such checks are performed when run-timecode generation is performed; of course, earlier checking ispreferable, but the Jumbo approach gives the programmergreat freedom to modularize her program, requiring onlythat the end result be correct. (Manifest type errors — thosethat are visible in the quoted code — can, in principle, becaught early by the Jumbo compiler; this is one goal of ourcurrent development.)We should mention that run-time code generation canalso be performed by more primitive methods. Sestoft [9]describes the use of various APIs for creating JVM classfiles at run time, in which the user provides the byte codesfor each method. Reflection can also be used to perform acertain amount of customization of programs [11]. The advantageof Jumbo — or any of the other systems mentionedin this section — over such approaches is that little moreis required of the programmer than the knowledge of Javawhich he already possesses.Jumbo uses the same language as metalanguage and objectlanguage, but this is mostly a convenience. In our earlierwork [6], the metalanguage and object language weredistinct — the former a functional language and the latteran imperative language. The only additional feature madepossible by having the same meta- and object language isthe possibility of unbounded levels of quotation. For parsingreasons, unbounded levels of quotation are not allowedin Jumbo at the moment.5 ConclusionsThe Jumbo system correctly compiles most of Java. Allthe examples shown in this paper compile and run as advertised.More information about Jumbo — including, in thenear future, the system itself — can be obtained from ourweb site, http://fuji.cs.uiuc.edu/Jumbo.Besides working on specific applications, we have twoimmediate goals with respect to the Jumbo system. The firstis to complete Jumbo by implementing inner classes. Atpresent, Jumbo compiles the rest of Java, but omits certainstatic checks (though they are discovered by the verifier); in8Proceedings of the International Symposium on Code Generation and Optimization (CGO’03)0-7695-1913-X/03 $17.00 © 2003 IEEE

essence, Jumbo produces the same code as javac. It willbe especially useful to have a complete implementation ofJava, because it will then be possible to quote — and thusabstract parts of — any Java code.The other goal is to optimize the code generation process.The structure of Jumbo should permit this to be donevery effectively: even if there is a hole in a piece of quotedJava code, most of the work involved in compiling thatcode can normally be done statically. In principle, the costof code generation could be dramatically reduced in mostcases. The resulting code-generating components could beused more routinely, since the need to amortizem the compilationcost would be that much less.The general idea of compositional compilation has broadapplicability. In [6], we described an earlier implementationtargetting SPARC machine code instead of JVM code. Targetingmachine code might be useful for producing code forsmall computers that cannot support a JVM. The conceptcan also be applied to other languages, although for manylanguages the implementation would be more complex thanJumbo.Security and correctness are major issues in this context.The behaviors of components can be hard to describe,since their “holes” can be filled by arbitrary Java fragments.The same problem appears in functional languages in whichfunctions can have side effects, and in object-oriented languagesin which a method can be overridden by anotherwith no enforceable constraints on the latter’s behavior. Towhat extent can the Jumbo compiler verify safety of the generatedcode? For that matter, to what extent can it be verifiedat code-generation time? These questions are the subjects ofcurrent research.In the meantime, the system offers a good deal of powerand is, we believe, very encouraging for the use of the twolevelapproach to code-generating components.[4] S.Frederick,G.Dan,M.Greg,H.Luke,andJ.Trevor.Compiling for run-time code generation. Technical report,Cornell University, October 2000.[5] Sam Kamin, Miranda Callahan, and Lars Clausen.Lightweight and generative components I: Source-levelcomponents. In Generative and Component-BasedSoftware Engineering (GCSE’99), volume 1799 ofLNCS, pages 49–62, September 1999.[6] Sam Kamin, Miranda Callahan, and Lars Clausen.Lightweight and generative components ii: Binarylevelcomponents. 1999.[7] Ralph Keller and Urs Hölzle. Binary Component Adaptation.Proc. ECOOP 98, Springer-Verlag LNCS 1445,pages 107–329, 1998.[8] Ulrik Pagh Schultz, Julia L. Lawall, Charles Consel,and Gilles Muller. Towards automatic specializationof Java programs. Lecture Notes in Computer Science,1628:367–390, 1999.[9] Peter Sestoft. Runtime Code Generation withJVM and CLR. Unpublished. Available athttp://www.dina.dk/ sestoft/publications.html. 2002.[10] Walid Taha and Tim Sheard. Multi-stage programmingwith explicit annotations. In Proceedings ofPEPM-97, volume 32 of ACM SIGPLAN Notices, pages203–217, June 1997.[11] S. Yamazaki, E. Shibayama. Runtime Code Generationfor Bytecode Specialization of Reflective Java Programs.Position paper for ECOOP’2002 Workshop onGenerative Programming, University of Mlaga, Spain.June 10-14, 2002.References[1] Don Batory, Bernie Lofaso, and Yannis Smaragdakis.JTS: Tools for implementing domain-specificlanguages. In Fifth International Conference on SoftwareReuse, pages 143–153. IEEE Computer society,June 1998.[2] Dawson R. Engler, Wilson C. Hsieh, and M. FransKaashoek. ‘C: A language for high-level, efficient, andmachine-independent dynaic code generation. In ConferenceRecord of POPL 1996, pages 131–144, January1996.[3] Michael Franz , Thomas Kistler . Slim binaries. Communicationsof the ACM 40:12, December 1997, 87–949Proceedings of the International Symposium on Code Generation and Optimization (CGO’03)0-7695-1913-X/03 $17.00 © 2003 IEEE