Péricles Alves

Just-in-time value specialization

JavaScript emerges today as one of the most important programming languages for the development of client-side web applications. Therefore, it is essential that browsers be able to execute JavaScript programs efficiently. However, the dynamic nature of this programming language makes it very challenging to achieve this much needed efficiency. In this paper we propose parameter-based value specialization as a way to improve the quality of the code produced by JIT engines. We have empirically observed that almost 60% of the JavaScript functions found in the worlds 100 most popular websites are called only once, or are called with the same parameters. Capitalizing on this observation, we adapt a number of classic compiler optimizations to specialize code based on the runtime values of functions actual parameters. We have implemented the techniques proposed in this paper in IonMonkey, an industrial quality JavaScript JIT compiler developed in the Mozilla Foundation. Our experiments, run across three popular JavaScript benchmarks, SunSpider, V8 and Kraken, show that, in spite of its highly speculative nature, our optimization pays for itself. As an example, we have been able to speedup SunSpider by 5.38%, and to reduce the size of its native code by 16.72%.

Runtime pointer disambiguation

To optimize code effectively, compilers must deal with memory dependencies. However, the state-of-the-art heuristics available in the literature to track memory dependencies are inherently imprecise and computationally expensive. Consequently, the most advanced code transformations that compilers have today are ineffective when applied on real-world programs. The goal of this paper is to solve this conundrum through dynamic disambiguation of pointers. We provide different ways to determine at runtime when two memory locations can overlap. We then produce two versions of a code region: one that is aliasing-free - hence, easy to optimize - and another that is not. Our checks let us safely branch to the optimizable region. We have applied these ideas on Polly-LLVM, a loop optimizer built on top of the LLVM compilation infrastructure. Our experiments indicate that our method is precise, effective and useful: we can disambiguate every pair of pointer in the loop intensive Polybench benchmark suite. The result of this precision is code quality: the binaries we generate are 10% faster than those that Polly-LLVM produces without our optimization, at the -O3 optimization level of LLVM.

DawnCC: Automatic Annotation for Data Parallelism and Offloading

Directive-based programming models, such as OpenACC and OpenMP, allow developers to convert a sequential program into a parallel one with minimum human intervention. However, inserting pragmas into production code is a difficult and error-prone task, often requiring familiarity with the target program. This difficulty restricts the ability of developers to annotate code that they have not written themselves. This article provides a suite of compiler-related methods to mitigate this problem. Such techniques rely on symbolic range analysis, a well-known static technique, to achieve two purposes: populate source code with data transfer primitives and to disambiguate pointers that could hinder automatic parallelization due to aliasing. We have materialized our ideas into a tool, DawnCC, which can be used stand-alone or through an online interface. To demonstrate its effectiveness, we show how DawnCC can annotate the programs available in PolyBench without any intervention from users. Such annotations lead to speedups of over 100× in an Nvidia architecture and over 50× in an ARM architecture.

Automatic Insertion of Copy Annotation in Data-Parallel Programs

Directive-based programming models, such as OpenACC and OpenMP arise today as promising techniques to support the development of parallel applications. These systems allow developers to convert a sequential program into a parallel one with minimum human intervention. However, inserting pragmas into production code is a difficult and error-prone task, often requiring familiarity with the target program. This difficulty restricts the ability of developers to annotate code that they have not written themselves. This paper provides one fundamental component in the solution of this problem. We introduce a static program analysis that infers the bounds of memory regions referenced in source code. Such bounds allow us to automatically insert data-transfer primitives, which are needed when the parallelized code is meant to be executed in an accelerator device, such as a GPU. To validate our ideas, we have applied them onto Polybench, using two different architectures: Nvidia and Qualcomm-based. We have successfully analyzed 98% of all the memory accesses in Polybench. This result has enabled us to insert automatic annotations into those benchmarks leading to speedups of over 100x.

Restrictification of function arguments

Pointer aliasing still hinders compiler optimizations, in spite of years of research on pointer disambiguation. Because the automatic disambiguation of pointers is a difficult endeavor, several programming languages offer programmers mechanisms to distinguish memory references, such as the “restrict” keyword in C. However, the use of such mechanisms is prone to human mistakes. In this paper we present a suite of automatic techniques that mitigate this problem. We have designed, implemented and tested three different ways to disambiguate pointers passed as arguments of functions. Our techniques combine static analyses to infer symbolic bounds of memory regions and code versioning. We generate a clone for each function whose arguments we can disambiguate and optimize it assuming the absence of aliasing among formal parameters. At runtime, we use the results of the symbolic interval tests to decide which version of a function we should call: the original one or the “restricted” clone, whenever we can prove that no aliasing can occur at runtime. An implementation of our restrictification methods in LLVM shows that we can vectorize up to 63% more operations than what could be accomplished using the -O3 optimization level of said compiler. When applying the optimization on OpenCV benchmarks, we have observed speedups as great as 40%.

Avoiding code pitfalls in Aspect-Oriented Programming

Aspect-Oriented Programming (AOP) is a maturing technique that requires a good comprehension of which types of mistakes programmers make during the development of applications. Unfortunately, the lack of such knowledge seems to represent one of the reasons for the cautious adoption of AOP in real software development projects. This paper reports on the results of a series of experiments whose main goal is to analyze and catalogue code pitfalls that are likely to lead programmers to make mistakes in AOP refactoring. Each experiment consists of a task that requires the aspectization of a crosscutting concern in one object-oriented application. Eight rounds of the experiment provided us with data of 98 AOP implementations from four crosscutting concerns in four different applications. Each participant of the experiment produced one implementation. Based on the analysis of these implementations, we (i) document six categories of recurring mistakes made by programmers, (ii) correlate these mistakes with the programmer expertise in object-oriented programming, years of software development, and pair programming, and (iii) derive a catalogue of code pitfalls which are likely to lead programmers to make the documented mistakes. We apply significance tests in order to statistically evaluate our results. We also present a prototype tool to warn programmers of the code pitfalls during refactoring activities.

ConcernReCS: finding code smells in software aspectization

Refactoring object-oriented (OO) code to aspects is an error-prone task. To support this task, this paper presents ConcernReCS, an Eclipse plug-in to help developers to avoid recurring mistakes during software aspectization. Based on a map of concerns, ConcernReCS automatically finds and reports error-prone scenarios in OO source code; i.e., before the concerns have been refactored to aspects.

Parameter based constant propagation

JavaScript is nowadays the lingua franca of web browsers. This programming language is not only the main tool that developers have to implement the client side of web applications, but it is also the target of frameworks such as Google Web Toolkit. Given this importance, it is fundamental that JavaScript programs can be executed efficiently. Just-in-time (JIT) compilation is one of the keys to achieve this much necessary efficiency. An advantage that a JIT compiler has over a traditional compiler is the possibility to use runtime values to specialize the target code. In this paper we push JIT speculation to a new extreme: we have empirically observed that many JavaScript functions are called only once during a typical browser section. A natural way to capitalize on this observation is to specialize the code produced by a function to the particular values that are passed to this function as parameters. We have implemented this approach on IonMonkey, the newest JIT compiler used in the Mozilla Firefox browser. By coupling this type of parameter specialization with constant propagation, a classical compiler optimization, we have been able to experimentally observe speedups of up to 25% on well-known algorithms. These gains are even more remarkable because they have been obtained over a worldly known, industrial quality JavaScript runtime environment.

A case for a fast trip count predictor

A fast heuristic to predict the trip count of loops.The heuristic predicts correctly the majority of the loops in SPEC 2006.The heuristic is O ( 1 ) .The heuristic allows us to invoke the Firefox JIT compiler earlier.The heuristics speeds up some JavaScript benchmarks by 5% to 27% in Firefox. The Trip Count of a loop determines how many iterations this loop performs. Predicting this value is important for several compiler optimizations, which yield greater benefits for large trip counts, and are either innocuous or detrimental for small ones. However, finding an exact prediction, in general, is an undecidable problem. Such problems are usually approached via methods which tend to be computationally expensive. In this paper we make a case for a cheap trip count prediction heuristic, which is O ( 1 ) on the size of the loop. We argue that our technique is useful to just-in-time compilers. If we predict that a loop will iterate for a long time, then we invoke the JIT compiler earlier. Even though straightforward, our observation is novel. We show how this idea speeds up JavaScript programs, by implementing it in Mozilla Firefox. We can apply our heuristic in 79.9% of the loops found in typical JavaScript benchmarks. For these loops, we obtain exact predictions in 91% of cases. We get similar results when analyzing the C programs of SPEC CPU 2006. A more elaborate technique, linear on the size of the loop, improves our O ( 1 ) technique only marginally. As a consequence of this work, we have been able to speed up several JavaScript programs by over 5%, reaching 24% of improvement in one benchmark.

Avoiding Code Pitfalls in Aspect-Oriented Programming

Aspect-Oriented Programming (AOP) is a maturing technique that requires a good comprehension of which types of mistakes programmers make during the development of applications. Unfortunately, the lack of such knowledge seems to represent one of the reasons for the cautious adoption of AOP in real software development projects. Based on a series of experiments, this paper reports a catalogue of code pitfalls that are likely to lead programmers to make mistakes in AOP. Each experiment required the aspectization (i.e. refactoring) of a crosscutting concern in one object-oriented application. Six rounds of the experiment provided us with the data of 80 aspect-oriented (AO) implementations where three crosscutting concerns were aspectized in three applications. We developed a prototype tool to warn programmers of the code pitfalls during refactoring activities.