Evaluating inlining techniques

Abstract For eciency and ease of implementation, many compilers implicitly impose an``inlining policy'' to restrict the conditions under which a procedure may be inlined. An inlining technique consists of an inlining policy and a strategy for choosing a sequence of inlining operations that is consistent with the policy. The eectiveness of an inlining technique is aected by the restrictiveness of the inlining policy as well as the eectiveness of the (heuristic) inlining strategy. The focus of this paper is on the comparison of inlining policies and techniques, and the notions of power and¯exibility are introduced. As a major case study, we identify and compare policies based on the version of the inlined procedure that is used

Storing and Querying Probabilistic XML Using a Probabilistic Relational DBMS

This work explores the feasibility of storing and querying probabilistic XML in a probabilistic relational database. Our approach is to adapt known techniques for mapping XML to relational data such that the possible worlds are preserved. We show that this approach can work for any XML-to-relational technique by adapting a representative schema-based (inlining) as well as a representative schemaless technique (XPath Accelerator). We investigate the maturity of probabilistic rela- tional databases for this task with experiments with one of the state-of- the-art systems, called Trio

Reify Your Collection Queries for Modularity and Speed!

Modularity and efficiency are often contradicting requirements, such that programers have to trade one for the other. We analyze this dilemma in the context of programs operating on collections. Performance-critical code using collections need often to be hand-optimized, leading to non-modular, brittle, and redundant code. In principle, this dilemma could be avoided by automatic collection-specific optimizations, such as fusion of collection traversals, usage of indexing, or reordering of filters. Unfortunately, it is not obvious how to encode such optimizations in terms of ordinary collection APIs, because the program operating on the collections is not reified and hence cannot be analyzed. We propose SQuOpt, the Scala Query Optimizer--a deep embedding of the Scala collections API that allows such analyses and optimizations to be defined and executed within Scala, without relying on external tools or compiler extensions. SQuOpt provides the same "look and feel" (syntax and static typing guarantees) as the standard collections API. We evaluate SQuOpt by re-implementing several code analyses of the Findbugs tool using SQuOpt, show average speedups of 12x with a maximum of 12800x and hence demonstrate that SQuOpt can reconcile modularity and efficiency in real-world applications.Comment: 20 page

Dynamic Virtual Join Point Dispatch

Conceptually, join points are points in the execution of a program and advice is late-bound to them. We propose the notion of virtual join points that makes this concept explicit not only at a conceptual, but also at implementation level. In current implementations of aspect-oriented languages, binding is performed early, at deploy-time, and only a limited residual dispatch is executed. Current implementations fall in the categories of modifying the application code, modifying the meta-level of an application, or interacting with the application by means of events—the latter two already realizing virtual join points to some degree. We provide an implementation of an aspect-oriented execution environment that supports truly virtual join points and discuss how this approach also favors optimizations in the execution environment

Common Subexpression Elimination in a Lazy Functional Language

Common subexpression elimination is a well-known compiler optimisation that saves time by avoiding the repetition of the same computation. To our knowledge it has not yet been applied to lazy functional programming languages, although there are several advantages. First, the referential transparency of these languages makes the identification of common subexpressions very simple. Second, more common subexpressions can be recognised because they can be of arbitrary type whereas standard common subexpression elimination only shares primitive values. However, because lazy functional languages decouple program structure from data space allocation and control flow, analysing its effects and deciding under which conditions the elimination of a common subexpression is beneficial proves to be quite difficult. We developed and implemented the transformation for the language Haskell by extending the Glasgow Haskell compiler and measured its effectiveness on real-world programs