Higher-order languages, such as Haskell, encourage the programmer to build abstractions by composing functions. A good compiler must inline many of these calls to recover an efficiently executable program. In principle, inlining is dead simple: just replace the call of a function by an instance of its body. But any compilerwriter will tell you that inlining is a black art, full of delicate compromises that work together to give good performance without unnecessary code bloat. The purpose of this paper is, therefore, to articulate the key lessons we learned from a full-scale "production" inliner, the one used in the Glasgow Haskell compiler. We focus mainly on the algorithmic aspects, but we also provide some indicative measurements to substantiate the importance of various aspects of the inliner. 1 Introduction One of the trickiest aspects of a compiler for a functional language is the handling of inlining. In a functional-language compiler, inlining subsumes several other optimisatio...

We have added a Java virtual machine (henceforth JVM) bytecode generator to the optimizing Scheme-to-C compiler Bigloo. We named this new compiler BiglooJVM. We have used this new compiler to evaluate how suitable the JVM bytecode is as a target for compiling strict functional languages such as Scheme. In this paper, we focus on the performance issue. We have measured the execution time of many Scheme programs when compiled to C and when compiled to JVM. We found that for each benchmark, at least one of our hardware platforms ran the BiglooJVM version in less than twice the time taken by the Bigloo version. In order to deliver fast programs the generated JVM bytecode must be carefully crafted in order to benefit from the speedup of just-in-time compilers.

Traditional database management systems perform updates-in-place and use logs and periodic checkpointing to efficiently achieve atomicity and durability. In this Thesis we shall present a different method, Shades, for achieving atomicity and durability using a copy-on-write policy instead of updates-in-place. We shall also present index structures and the implementation of Shines, a persistent functional programming language, built on top of Shades. Shades includes real-time generational garbage collection. Real-timeness is achieved by collecting only a small part, a generation, of the database at a time. Contrary to previously presented persistent garbage collection algorithms, Shades has no need to maintain metadata (remembered sets) of intra-generation pointers on disk since the metadata can be reconstructed during recovery. This considerably reduces the amount of disk writing. In conjunction with aggressive commit grouping, efficient index structures, a design specialized to a main memory environment, and a carefully crafted implementation of Shines, we have achieved surprisingly high performance, handsomely beating commercial database management systems.

Hop is a new language for programming interactive Web applications. It aims to replace HTML, JavaScript, and server-side scripting languages (such as PHP, JSP) with a unique language that is used for client-side interactions and server-side computations. A Hop execution platform is made of two compilers. One that compiles the code executed by the server, and one that compiles the code executed by the client. This paper presents the latter. In order to ensure compatibility of Hop graphical user interfaces with popular plain Web browsers, the client-side Hop compiler has to generate regular HTML and Java-Script code. Since the Hop language is built on top of the Scheme programming language, compiling Hop to JavaScript is nearly equivalent to compiling Scheme to JavaScript. The compiler we have designed supports the whole Scheme core language. In particular it features proper tail recursion. However complete tail recursion optimization slows down the generated code. Compared to hand-written code, programs are in the worst case more than two times slower. However in Hop we use a relaxed version of proper tail recursion in which case the generated code runs roughly at the same speed as hand-written code. The techniques presented in this paper can be applied to most strict functional languages such as ML and Lisp. 1

Many optimizations are easier or more effective for straight-line code (basic blocks). Straight-line code in Forth is limited mainly by calls and returns. Inlining eliminates calls and returns, which in turn makes the basic blocks longer, and increases the effectiveness of other optimizations. In this paper we present a first prototype implementation of ininlining for Gforth. 1

This paper presents a on-chip stack based memory organization that effectively reduces the energy dissipation in programmable embedded system architectures. Most embedded systems use the notion of stack for implementation of function calls. However, such stack data is stored in processor address space, typically in the main memory and accessed through caches. Our analysis of several benchmarks show that the callee saved registers and return addresses for function calls call constitute a significant portion of the total memory accesses. We propose a separate stack-based memory organization to store these registers and return addresses. Our experimental results show that effective use of such stack-based memories yield significant reductions in system power/energy, while simultaneously improving the system performance. Application of our approach to the SPECint95 and MediaBench benchmark suites show a reduction of up to 32.5% reduction in energy in L1 data cache, with marginal improvements in system performance.

This paper presents the compilation of the Scheme programming language to.NET. This platform provides a virtual machine, the Common Language Runtime (CLR), that executes bytecode, the Common Intermediate Language (CIL). Since CIL was designed with language agnosticism in mind, it provides a rich set of language constructs and functionalities. As such, the CLR is the first execution environment that offers type safety, managed memory, tail recursion support and several flavors of pointers to functions. Therefore, the CLR presents an interesting ground for functional language implementations. We discuss how to map Scheme constructs to CIL. We present performance analyses on a large set of real-life and standard Scheme benchmarks. In particular, we compare the speed of these programs when compiled to C, JVM and.NET. We show that in term of speed performance of the Mono implementation of.NET, the best implementing running on both Windows and Linux, still lags behind C and fast JVMs such as the Sun’s implementations.

All modern compilers provide inlining, an optimization which replaces a function call by the function body. Implementations of inlining are usually focused on specic source languages or on specic algorithms to decide which functions should be inlined. We describe the implementation of a general inlining implementation in the program transformation language Stratego. This inliner should be usable for dierent source languages and decision algorithms. The implementation separates the analysis and transformation of the program, the traversal of the program and the decision when to do inlining. In addition, the implementation of several other optimizations that are enabled by inlining is discussed in the context of the highly optimizable Pan language. Contents 1

We have added a Java virtual machine (henceforth JVM) bytecode generator to the optimizing Scheme-to-C compiler Bigloo. We named thisnew compiler BiglooJVM. We have used this new compiler to evaluate how suitable the JVM bytecode isasa target for compiling strict functional languagessuch asScheme. In thispaper, we focuson the performanceissue. Wehavemeasuredtheexecutiontimeofmany Scheme programswhen compiled to C and when compiled to JVM. We found that for each benchmark, at least one of our hardware platformsran the BiglooJVM version in less than twice the time taken by the Bigloo version. In order to deliver fast programs the generated JVM bytecode must be carefully crafted in order to benefit from the speedup of just-in-time compilers.

El objetivo de la presente tesis es investigar acerca del diseño de lenguajes orientados a objetos y las diferentes técnicas existentes para ofrecer garantías estáticas de verificación. En particular, nos interesa definir un calificador de tipos acíclicos, que asegure que la clausura transitiva de la relación pointsto de una instancia acíclica sea irreflexiva. Listas enlazadas y árboles son típicos ejemplos de tipos acíclicos. Dicha propiedad es interesante debido a que: i) las estructuras de datos acíclicas pueden ser fácilmente recolectadas utilizando una estrategia de conteo de referencias (reference counting), y ii) es sencillo garantizar la terminación de ciclos que recorren estructuras de datos acíclicas. La discusión sobre aciclicidad nos llevará a entender cuán difícil es garantizarla con las herramientas disponibles en la actualidad. Desde el punto de vista técnico, propusimos un lenguaje con un calificador de clases opcional “acíclico”. El mismo impone algunas restricciones de tipado: si la clase A es declarada como acíclica y A contiene un campo “f ” de tipo B, entonces B debe ser acíclico también. La aciclicidad es entonces forzada por construcción, o sea, agregando una precondición especial a la asignación “a.f: = b”, para “a ” una instancia acíclica, que garantice la preservación de la aciclicidad de “a ” y “b”. La especificación es lograda utilizando una variación del trabajo realizado en dynamic frames. Uno de los problemas más interesantes a resolver