15 phone 703.661.1580 • in the U.S. phone 1.800.645.7247 • fax 703.661.1501 J UL y- DECEMBER 2013 C ATALOG o nl I ne r e S ource S Wo RLD B AN k eL IBRAR y elibrary.worldbank.org World b ank e l ibrary is a subscription-based website designed to meet the unique needs of researchers and librarians. Now in its 10th year and built on a state-of-the-art platform, access to World Bank research and knowledge is faster, easier, and more convenient than ever. eLibrary subscribers are assured full and immediate access to the complete collection of 9,000+ World Bank publications. Beyond its exhaustive content, eLibrary offers a variety of tools and added functionality that save users valuable time during their research. Personalization tools and time-saving conveniences for users: n Bookmarking content for quick retrieval n Saving and emailing search results n eAlerts and RSS feeds based on content type or search criteria n Citation alerts and exporting tools n Easy sharing through social media

y Natalia Kulichenko and Jens Wirth Concentrating solar thermal technologies have a clear potential for scaling up renewable energy at the utility level, thereby diversifying the generation portfolio mix, powering development, and mitigating climate change. The report analyzes current experience in designing and implementing regulatory frameworks supporting the technology Wo RLD B AN k S T u DI e S July 2012. 178 pages. Stock no. C19607 (ISBN: 978-0-8213-9607-0). US$25.95

For every control-flow branch in the source program, the recorder generates conditional exit LIR instructions. These instruc- tions exit from the trace if required control flow is different from what it was at trace recording, ensuring that the trace instructions are run only if they are supposed to. We call these instructions guard instructions. Most of our traces represent loops and end with the special loop LIR instruction. This is just an unconditional branch to the top of the trace. Such traces return only via guards. Now, we describe the key optimizations that are performed as part of recording LIR. All of these optimizations reduce complex dynamic language constructs to simple typed constructs by spe- cializing for the current trace. Each optimization requires guard in- structions to verify their assumptions about the state and exit the trace if necessary. Type specializa

Hence, recording and compiling a trace speculates that the path and typing will be exactly as they were during recording for subsequent iterations of the loop. Every compiled trace contains all the guards (checks) required to validate the speculation. If one of the guards fails (if control flow is different, or a value of a different type is generated), the trace exits. If an exit becomes hot, the VM can record a branch trace starting at the exit to cover the new path. In this way, the VM records a trace tree covering all the hot paths through the loop. Nested loops can be difficult to optimize for tracing VMs. In a na ̈ ıve implementation, inner loops would become hot first, and the VM would start tracing there. When the inner loop exits, the VM would detect that a different branch was taken. The VM would try to record a branch trace, and find that the trace reaches not the inner loop header, but the outer loop header. At this point, the VM could continue tracing until it reaches the inner loop header again, thus tracing the outer loop inside a trace tree for the inner loop. But this requires tracing a copy of the outer loop for every side exit and type combination in the inner loop. In essence, this is a form of unintended tail duplication, which can easily overflow the code cache. Alternatively, the VM could simply stop tracing, and give up on ever tracing outer loops. We solve the nested loop problem by recording nested trace trees . Our system traces the inner loop exactly as the na ̈ ıve version. The system stops extending the inner tree when it reaches an outer loop, but then it starts a new trace at the outer loop header. When the outer loop reaches the inner loop header, the system tries to call the trace tree for the inner loop. If the call succeeds, the VM records the call to the inner tree as part of the outer trace and finishes the outer trace as normal. In this way, our system can trace any number of loops nested to any depth without causing excessive tail duplication. These techniques allow a VM to dynamically translate a pro- gram to nested, type-specialized trace trees. Because traces can cross function call boundaries, our techniques also achieve the ef- fects of inlining. Because traces have no internal control-flow joins, they can be optimized in linear time by a simple compiler (10). Thus, our tracing VM efficiently performs the same kind of op- timizations that would require interprocedural analysis in a static optimization setting. This makes tracing an attractive and effective tool to type specialize even complex function call-rich code. We implemented these techniques for an existing JavaScript in- terpreter, SpiderMonkey. We call the resulting tracing VM Trace- Monkey . TraceMonkey supports all the JavaScript features of Spi- derMonkey, with a 2x-20x speedup for traceable programs. This paper makes the following contributions: • We explain an algorithm for dynamically forming trace trees to cover a program, representing nested loops as nested trace trees. • We explain how to speculatively generate efficient type-specialized code for traces from dynamic language programs. • We validate our tracing techniques in an implementation based on the SpiderMonkey JavaScript interpreter, achieving 2x-20x speedups on many programs. The remainder of this paper is organized as follows. Section 3 is a general overview of trace tree based compilation we use to cap- ture and compile frequently executed code regions. In Section 4 we describe our approach of covering nested loops using a num- ber of individual trace trees. In Section 5 we describe our trace- compilation based speculative type specialization approach we use to generate efficient machine code from recorded bytecode traces. Our implementation of a dynamic type-specializing compiler for JavaScript is described in Section 6. Related work is discussed in Section 8. In Section 7 we evaluate our dynamic compiler based on 1 for (var i = 2; i < 100; ++i) { 2 if (!primes[i]) 3 continue; 4 for (var k = i + i; i < 100; k += i) 5 primes[k] = false; 6 } Figure 1. Sample program: sieve of Eratosthenes. primes is initialized to an array of 100 false values on entry to this code snippet. Interpret Bytecodes Monitor Record LIR T race Execute Compiled T race Enter Compiled T race Compile LIR T race Leave Compiled T race loop edge hot loop/exit abort