PARALLELIZING JAVA PROGRAMS USING … · 2016-07-12 · grama Java em uma forma normal que utiliza...

Universidade Federal de PernambucoCentro de Informatica

Pos Graduacao em Ciencia da Computacao

PARALLELIZING JAVA PROGRAMS USINGTRANSFORMATION LAWS

Rafael Machado Duarte

DISSERTACAO DE MESTRADO

Recife22 de agosto de 2008

Universidade Federal de PernambucoCentro de Informatica

Rafael Machado Duarte

PARALLELIZING JAVA PROGRAMS USING TRANSFORMATIONLAWS

Trabalho apresentado ao Programa de Pos Graduacao em

Ciencia da Computacao do Centro de Informatica da Uni-

versidade Federal de Pernambuco como requisito parcial

para obtencao do grau de Mestre em Ciencia da Com-

putacao.

Orientador: Alexandre Cabral Mota

Co-orientador: Augusto Cezar Alves Sampaio

Recife22 de agosto de 2008

Duarte, Rafael Machado Parallelizing Java programs using transformation laws / Rafael Machado Duarte. - Recife: O Autor, 2008. xix, 77 p. : il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da computação, 2008.

Inclui bibliografia e apêndice. 1. Engenharia de software. 2. Métodos formais. 3. Leis de transformação. I. Título. 005.1 CDD (22. ed.) MEI2010 – 079

aos meus pais

ACKNOWLEDGEMENTS

If you wish your merit to be known, acknowledge that of other people.

—ORIENTAL PROVERB

Muitas pessoas contribuıram para a conclusao desta dissertacao de mestrado. Algu-mas cientes de que estavam ajudando, outras nao. Cita-las nos agradecimentos e sempredifıcil, pois tenho que decidir quais nomes serao incluıdos. Citarei as pessoas mais direta-mente envolvidas em meu trabalho, mas deixo registrado meus agradecimentos a todos,que mesmo nao aqui citados, colaboraram para a conclusao deste trabalho.

Comeco agradecendo aos professores Alexandre Mota e Augusto Sampaio. Sem aorientacao deles, esse trabalho seria impossıvel. Agradeco tambem pelo tempo quededicaram a meu trabalho, o que me proporcionou as condicoes necessarias ao terminodesta dissertacao.

A minha famılia, agraceco por todo o apoio que me foi dado, especialmente a meuirmao felipe, pela consultoria na area de estatıstica.

Muito importante tambem foi o apoio de todos meus colegas da pos graduacao do CIn,pelo companheirismo e por terem me proporcionado varios momentos de descontracaodurante o atribulado cotidiano de um mestrando.

Dedico um agradecimento especial a Natalia, minha namorada, por ter me apoiadoesse tempo todo e ter tornado minha vida mais feliz pelo tempo que tenho desfrutado desua companhia.

Agradeco tambem aos professores Marcio Cornelio e Paulo Borba, por terem aceitoparticipar de minha banca e pelos relevantes comentarios que fizeram sobre meu trabalho.

Finalmente, agradeco ao CNPq, por ter financiado parcialmente este projeto de mestrado.

vii

�Fais de ta vie un reve, et d’un reve, une realite.�

—ANTOINE DE SAINT-EXUPERY

RESUMO

Com a adocao pelo mercado dos processadores de nucleos multiplos, o uso de threads emJava se torna cada vez mais proveitoso. O desenvolvimento de sistemas paralelos e, entre-tanto, uma tarefa que poucos desenvolvedores estao capacitados a enfrentar. Dado essecontexto, foi desenvolvida uma abordagem de paralelizacao de programas java baseadaem leis de transformacao, com o intuito de facilitar esse processo e permitir uma par-alelizacao sistematica.

O primeiro passo da abordagem utiliza leis de transformacao para converter um pro-grama Java em uma forma normal que utiliza um conjunto restrito de recursos da lin-guagem. Neste passo, foram definidas leis de transformacao adaptadas de trabalhosanteriores, assim como novas leis foram propostas.

A partir de um programa na forma normal, sao utilizadas regras de transformacaofocadas em introduzir paralelismo. Apos a aplicacao dessas regras de acordo com aestretegia desenvolvida, um programa paralelo e produzido.

Dois casos de estudo foram realizados para validar a abordagem: calculo de series deFourier e o algoritmo de criptografia IDEA. Ambos codigos foram obtidos do Java GrandeBenchmark Suite. A execucao dos estudos de caso comprova o exito da abordagem emmelhorar a performance do codigo original.

Palavras-chave: Java, Programacao Paralela, Leis de Transformacao

xi

ABSTRACT

With the ever increasing adoption of multicore processors by the market, using Javathreads becomes very fruitful. Developing parallel systems, though, is a task few devel-opers are able to face. Given this context, we developed a parallelization approach basedon transformation laws, which intends to facilitate this process and provide a systematicparallelization.

The first step of our approach uses transformation laws to convert a Java programinto a normal form that allows only a restricted set of features from the language. In thisstep, some laws were adapted from previous work, as well as new laws were defined.

Starting from a program in the normal form, tranformation rules focused on intro-ducing parallelism are used. After applying these rules in accordance to the developedstrategy, a parallel program is produced.

Two case studies were performed to validate our approach: Fourier series calculationand the IDEA encryption algorithm. Both source codes were obtained from the JavaGrande Benchmark suite. The experiments we performed provided very interesting re-sults, delivering parallel code with a performance comparable to manually parallelizedones.

Keywords: Java, Parallel Programming, Transformation Laws

xiii

CONTENTS

Chapter 1—Introduction 1

1.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Chapter 2—Background 5

2.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Concurrency Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Algebraic Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Program Parallelization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Dependence Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Final Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapter 3—Normal Form Reduction 15

3.1 Open systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.2 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.4 Constructors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.5 Commands and Expressions . . . . . . . . . . . . . . . . . . . . . 38

3.2.6 Summary of Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3 Normal Form Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3.1 Normal Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.2 Reduction Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


Chapter 4—Parallelization 49

4.1 Parallelization Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Parallelization Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53


xv

xvi CONTENTS

Chapter 5—Case Studies 57

5.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2 Fourier Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.3 IDEA Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.4 Final Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Chapter 6—Concluding Remarks 63

6.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Appendix A—Exp1 Interpreter Source Code 73

A.1 Original Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A.2 Normalized classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

LIST OF FIGURES

1.1 Overview of our strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Example of parallelization . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Threads in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Defining threads using inheritance . . . . . . . . . . . . . . . . . . . . . . 62.3 Defining threads using interface implementation . . . . . . . . . . . . . . 72.4 The lifecycle of a Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Synchronized method example . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Synchronized block example . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 General open system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Limited open system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Exp1 interpreter (original class diagram) . . . . . . . . . . . . . . . . . . 453.4 Exp1 interpreter class diagram (attributes moved up and reduced construc-

tors) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.5 Exp1 interpreter class diagram (methods moved up) . . . . . . . . . . . . 463.6 Exp1 interpreter class diagram (normal form) . . . . . . . . . . . . . . . 47

4.1 Source code of class Main . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2 Source code of method eval after reordering . . . . . . . . . . . . . . . . 554.3 Source code of method eval parallelized . . . . . . . . . . . . . . . . . . . 56

5.1 Fourier series benchmark starting classes . . . . . . . . . . . . . . . . . . 585.2 Fourier series benchmark in the normal form . . . . . . . . . . . . . . . . 595.3 Execution time in the different Fourier implementations . . . . . . . . . . 605.4 Speedups in the different Fourier implementations . . . . . . . . . . . . . 605.5 IDEA encryption benchmark starting classes . . . . . . . . . . . . . . . . 615.6 IDEA encryption benchmark in the normal form . . . . . . . . . . . . . . 615.7 Execution time in the different IDEA implementations . . . . . . . . . . 625.8 Speedups in the different IDEA implementations . . . . . . . . . . . . . . 62

xvii

LIST OF TABLES

3.1 Complete set of laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 Fourier series benchmark execution data . . . . . . . . . . . . . . . . . . 605.2 IDEA encryption benchmark execution data . . . . . . . . . . . . . . . . 62

xix

CHAPTER 1

INTRODUCTION

There is nothing more difficult to take in hand, more perilous to conduct

or more uncertain in its success than to take the lead in the introduction

of a new order of things.

—NICCOLO MACHIAVELLI (”The Prince”)

Developing parallel applications is a major challenge for programmers. Parallel sys-tems can present issues which do not occur in their sequential counterparts, like non-determinism, race conditions, and deadlocks [And00]. Reasoning with these issues isconsidered more difficult than reasoning with ordinary sequential programs. Thus, fewdevelopers specialize on this kind of software, and a great amount of time is spent on itsdevelopment.

Nowadays, multicore processors are widely available to ordinary PCs [Rat05], andto explore their multiple processing capabilities, the running softwares must be multi-threaded. It becomes clear that a powerful hardware resource is not being exploited asit could.

One possible way to overcome these difficulties is to provide some parallelization mech-anism. The idea is to hide the parallelism from the developer, either by an automaticprocess, either by providing high-level abstractions. These techniques, known as implicitparallelism, can take an ordinary sequential program and, with minor or no human in-terference, produce a parallel version of that program. They can be more cost-effectivethan explicit parallelism, when executing the original sequential system in parallel doesnot require a major restructuring.

By hiding the parallelism from the developer, it becomes possible to explore it, withoutthe need of manipulating error prone parallel code. These techniques are well establishedin the supercomputing community, with reliable tools in use for languages such as HighPerformance Fortran [KLZS94].

As a language to explore parallelism in general computing, Java [GJSB05] is as avery interesting alternative. Recent surveys indicated that it is one of the most popularprogramming languages today [Tio08]. Beyond this, Java supports parallel programmingwith built-in threads, and has already proved its capabilities in different domains, suchas web applications and even scientific computing [MMG00].

Some approaches have been proposed to explore implicit parallelism in Java, suchas [BA07, CA04, Fel03, Che03, MMG+01]. They work both in the bytecode and sourcecode level, and a common point among them is the additional support necessary. Thissupport is provided by extra code introduced in the application, or by additional runtimetools. They provide good results, but they explore the parallelization in a very pragmaticway, without focusing on the correctness of the transformations. One promising approach

1

2 INTRODUCTION

to address this issue is the use of algebraic laws. They can define the equivalence betweentwo systems, as well as be used to relate sequential and parallel versions of the samesystem.

Algebraic laws have been defined for languages of several programming paradigms [HHJ+87,RH88, QJ94, SSH99, BSCC04, SB06]. They provide insight on the algebraic seman-tics of languages, and are also used as a basis for the definition of reliable refactor-ings [Cor04, GM05]. By using them, a framework for formal proofs can be established,which facilitates assuring the correctness of the transformations.

Our work proposes a strategy to parallelize Java programs using algebraic laws. Itsgoal is to provide a lightweight program transformation scheme, more amenable to futureformal proofs, and capable of speeding up the execution of Java programs executed inmultiple processors. By lightweight program transformations we mean they are verysimple, when compared to other parallelization frameworks, which often perform complexcode transformations and require the use of classes from third party libraries.

We were inspired by the ideas presented in [Sam97, SB06], but adapting them toa more practical scenario, using Java, which proved to be challenging. Our strategyconsists in two major activities, as can be seen in Figure 1.1. We first use algebraiclaws to transform the original source code into a normal form, using a normal formreduction strategy (Section 3.3). Our normal form, similarly to [SB06], moves mostof the code to the method main, which in our case, is defined within the class calledMain. Only the attributes are maintained in a newly created Object class. After that,we use our parallelization strategy to introduce parallelism into the normalized program(Section 4.2).

Figure 1.1 Overview of our strategy

To provide a closer look on how our strategy works, consider the code depicted inFigure 1.2, which is already in the normal form to ease the discussion. In this code,there is a sequence of six commands, explicitly enumerated. By performing a dependenceanalysis we can discover that the commands at lines 3 and 6 are independent of thoseat 1, 2, 4, and 5. Thus, the commands 3 and 6 do not depend on the computationsperformed by the other commands, and vice-versa. That is, there is no need of orderingin their execution. In this situation, we can group the related commands, by moving them

1.1 CONTRIBUTIONS 3

to form two new partitions; finally, we execute each partition in parallel, exploring themultiple processors possibly available. In our strategy, changing the order of commandsand their parallel execution will be achieved by applying the laws we propose.

Figure 1.2 Example of parallelization

To evaluate whether our strategy delivers significant performance improvements inreal-world systems, we perform two case studies using the source code from the JavaGrande Benchmark suite (JGB) [SBO01]. Our experiments provided some evidence thatour strategy can be applied in practice, delivering competitive speedups when comparedto parallel code manually written by the developers of the suite. In one case study weobtained practically the same speedup (0.2% better, 78.6% vs 78.5%) than the parallelversion created by hand, while the other delivered a 24% worse speedup (54.24% vs70.53%), which we consider competitive, if we take into account the effort involved indeveloping each version.

Although we do not provide formal proofs for our laws, in the experiments with thecase studies, the observed behavior is preserved. Each case study has a built-in valida-tion mechanism to check wether the results are correct. After using our parallelizationstrategy, the code continued to successfully pass the existing validations.

1.1 CONTRIBUTIONS

The summary of our contributions is presented as follows:

Adaptation of ROOL laws to Java - the laws defined for ROOL [BS00] were adaptedto a subset of Java, where some of them required substantial modification or eventhe definition of new laws.

Proposition of new laws for Java - laws for features not present in ROOL, such asconstructors, were proposed.

Approach to cope with limited open systems - previous work involving laws forobject-oriented programming required the system to be closed, i.e. no binary ex-ternal code could be used. We have devised a solution to address a limited form ofopen systems, enabling them as targets for the laws.

Normal form reduction strategy for Java - a reduction strategy for Java is pro-vided to transform Java programs (with a restricted set of constructs) into a normalform that uses a limited set of features of the language.

4 INTRODUCTION

Parallelization laws - a novel strategy to parallelization that provides lightweight sourceto source transformations and a framework for building correctness proofs. More-over, they provide a way to improve the performance of sequential systems, exploit-ing available multiple processors.

1.2 ORGANIZATION

The remaining of this thesis is divided into five chapters and one appendix. The contentsof each one is described as follows:

Chapter 2: we introduce the main concepts involved in the subsequent chapters. Itpresents Java, our target language, focusing on its concurrency features; describesthe main concepts about algebraic laws, the strategy used in our work; and itdiscusses about program parallelization and its challenges, the domain where wefocused our work.

Chapter 3: we discuss in depth the algebraic set of laws devised for Java, the strategyto cope with open systems, the proposed normal form, and the reduction strategy.

Chapter 4: we describe the strategy to parallelize sequential Java programs. We alsopresent the transformation laws focused on restructuring the code for parallel exe-cution.

Chapter 5: we discuss two case studies we have performed, describing the applicationof our strategy from the original Java source code until it becomes parallel. Wealso compare our normal form and parallel version with those from the JGB.

Chapter 6: we present our concluding remarks, as well as some significant related work,and future improvements to our current work.

Appendix A: the source code of the example used in Chapter 3 is presented.

CHAPTER 2

BACKGROUND

When a man’s knowledge is not in order, the more of it he has, the

greater will be his confusion.

—HERBERT SPENCER

This chapter briefly introduces the main concepts involved in this work. Its purpose isto provide the background needed to understand the subsequent chapters. The first sec-tion gives an overview of Java, our target language, focusing on its concurrency features;the next one discusses about algebraic laws, the approach we have used in our work; andthe final section presents the main topics about program parallelization, the area wherewe focused the use of algebraic laws.

2.1 JAVA

Java [GM96] was conceived in 1991, originally designed for embedded software. Never-theless, in 1994, it had its focus redirected to the internet, and started to bring attentionfrom the developers community. Since then, Java’s popularity has greatly increased, justas it happened to C, due to the popularity of UNIX systems. According to [GM96], itsmajor features are:

Simple, object oriented, and familiar - object orientation is the current dominantparadigm in the industry. Java’s model is simple and very similar to C++;

Robust - compile and runtime verifications assure the reliability of programs.

Distributed and safe - a language and runtime system designed to execute in dis-tributed environments has to incorporate security aspects;

Interpreted, portable and neutral architecture - by using a virtual machine to ex-ecute bytecodes (java compiled code), which are platform independent, it providesthe portability to execute them on different platforms.

High performance - techniques like just-in-time (JIT) compilation allow critical per-formace code to be compiled to native code, speeding up execution and reducingthe overheads caused by interpretation.

Dynamic - classes are loaded only when needed, and new classes can be added as thesystem evolves.

Multithreaded - built-in support to concurrent programming allows the developmentof portable multithreaded applications.

5

6 BACKGROUND

2.1.1 Concurrency Model

Actually, Java is one of the most interesting concurrent object oriented languages [Wel04].Since its conception, it was designed to provide a concurrency model within the objectoriented framework. It was done by using the concept of active objects, which have theirown behavior, in contrast to the passive ones that only respond to external calls.

In Java, active objects can be defined in two ways: creating a new class that inheritsfrom Thread, or creating a new class that implements the interface Runnable, as depictedin Figure 2.1. To execute a newly created thread, one must call the method start. Itthen executes the commands from the method run in an independent execution thread(in parallel).

Figure 2.1 Threads in Java

To define a thread using inheritance, one firstly must define a class that extends fromthe class Thread (defined in Java’s standard library), and redefine the method run. Themethod run defines the behavior of the thread. Its body has the commands to be executedin a new thread. To execute a thread defined in this way, it suffices to create an objectfrom the defined class, and call its start method, as depicted in Figure 2.2.

public class HelloWorldThread extends Thread {

public void run() {

System.out.println("Hello World!");

}

public static void main(String[] args) {

HelloWorldThread helloWorld = new HelloWorldThread();

helloWorld.start();

}

}

Figure 2.2 Defining threads using inheritance

2.1 JAVA 7

In the other way, the user defined class implements the Runnable interface. Thisinterface defines only the run method, that must be implemented by the class. It isan alternative to cases where the class defining the run method already inherits fromanother class (Java supports only single inheritance). Figure 2.3 depicts how the previousexample could be coded in this approach.

public class HelloWorldRunnable implements Runnable {

public void run() {

System.out.println("Hello World!");

}

public static void main(String[] args) {

HelloWorldRunnable helloWorld = new HelloWorldRunnable();

Thread thread = new Thread(helloWorld);

thread.start();

}

}

Figure 2.3 Defining threads using interface implementation

The life cycle of a thread can be observed in Figure 2.4. When it is created, it remainsidle until the start method is called. At this moment it changes to the running state.In this state, it can let other threads execute when the yield method is called whileremaining in the execution queue, as well as the virtual machine can interrupt it, and letother threads execute. It can also move to the not runnable state when the methods waitor sleep are executed. When the run method finishes, the thread goes to the dead state.

Figure 2.4 The lifecycle of a Thread

The Thread class presents useful methods to control its execution. Among them, wehighlight the following ones:

start - starts the execution of the thread as an independent task, calling the run methoddefined by the programmer. When the run method finishes, the thread is finalized;

stop - stops the thread execution. This method is deprecated, because it is deadlockprone [Sun99];

8 BACKGROUND

isAlive - returns true if the thread has started its execution, but not yet finished;

sleep - suspends the thread execution by a determined period of time;

join - waits until the thread finishes. It can also receive a timeout as parameter, to avoidwaiting for undetermined time; and

yield - suspends the thread execution, letting other threads execute

Concurrency Control In Java, the standard method adopted for inter-thread com-munication is memory sharing, which happens when two or more threads access the sameobject. Sharing memory between threads is one of the major sources of bugs in mul-tithreaded software [GPB+06]. There are three basic alternatives to avoid this kind ofproblem:

� Do not share objects between threads;

� Make shared objects immutable;

� Access the shared area exclusively.

When mutable objects must be shared, the only solution is to control the access tothat shared area, assuring that only one thread has access to it at a time . In Java,it can be achieved by using its locking mechanism, that provides each object with itsown lock. This lock is then used by synchronization to avoid simultaneous access tothe same memory area. There are two ways of using synchronization in Java: using thesynchronized modifier in method declarations, or using synchronized blocks.

When a method is marked as synchronized, it can be executed only if it obtains thelock from the object it is being executed on. By using this technique, no more than onethread can execute the same method, on the same object, simultaneously. The rule ofthumb is that every method accessing shared members in an object must be synchronizedif multiple threads execute that method. An example with synchronized is depicted inFigure 2.5.

public synchronized void write(int newValue) {

theData = newValue;

}

Figure 2.5 Synchronized method example

Synchronized blocks provide the same locking mechanism, but in a more flexible way.One can declare a synchronized block, specify from which object it will use the lock,and enclose within it the code to be executed in a mutually exclusive fashion. Theydeliver a finer grained synchronization, while the synchronized modifier affects the entiremethod body. Moreover, the lock is not fixed. This means that the lock being used is

2.2 ALGEBRAIC LAWS 9

public void write(int newValue) {

synchronized(this) {

theData = newValue;

}

}

Figure 2.6 Synchronized block example

defined by an object passed as parameter to the block. The previous example, codedusing synchronized blocks, is depicted in Figure 2.6.

There are more concurrency control features in Java, such as the modifier volatile,used to provide atomic accesses to primitive type attributes; and the methods wait, andnotify, used to implement conditional synchronization. We do not provide further details,since they are not used in this work.

2.2 ALGEBRAIC LAWS

Formal semantics are used to precisely specify the meaning of programs by using rigorousmathematical abstractions. According to [Win93], there are three major styles to definethe semantics of a program language:

Denotational semantics translates phrases in the language into a denotation, i.e. aphrase in some other language. It uses abstract mathematical concepts as de-notations to language constructs. Denotational semantics corresponds loosely tocompilation, but the target language is a mathematical formalism, instead of aprogramming language.

Operational semantics describes directly the execution of a program. It is done byspecifying how it executes on an abstract machine. Operational semantics cor-responds loosely to interpretation, where the interpretation language is usually amathematical formalism.

Axiomatic semantics tries to fix the meaning of a programming construct by givingproof rules for it within a program logic. It emphasizes proof of correctness rightfrom the start.

Defining a set of algebraic laws for a language is a common way of defining its seman-tics in an axiomatic style. Algebraic laws define equations that establish the equivalencebetween elements in the language, a very useful tool to build proofs and verify systems.

Algebraic laws for programming languages adopt a principle widely used in mathe-matics [HHJ+87], where a theory is built around its axiomatic laws. The Arithmetics,for example, provides us with several laws, such as:

Laws (1), and (3) enounce the symmetry of the addition and multiplication operators.Laws (2), and (4) establish the identity operands for both operations. These laws aresuccessfully used to define the properties of the arithmetic’s operators. We can use the

10 BACKGROUND

(1) x× y = y × x

(2) x× 1 = x

(3) x+ y = y + x

(4) x+ 0 = x

same approach to define properties of programming languages. For instance, assigning Pto itself does not have any effect in the program execution; therefore it is equivalent toskip (the empty command).

P := P = skip

This is an example of a very simple law for an imperative language, taken from [HHJ+87].Algebraic laws have been successfully defined for the most important paradigms of pro-gramming languages [HHJ+87, RH88, QJ94, SSH99, SB06], and proved to be a usefulapproach to provide their semantics.

An algebraic approach to provide the semantics of a programming language raises theissue of completeness. It is well known that there is no complete and consistent set ofaxioms, as stated by Godel’s incompleteness theorem. Nevertheless, it is paramount toaddress their comprehensiveness; to establish that they are expressive enough to definethe semantics of the language. In this sense, a standard approach is to provide a reductionstrategy, that, using the defined laws, leads to the reduction of any program to a normalform. This normal form features only a limited set of language constructs, usually themost simple ones.

More recently, algebraic laws have been used to provide a formal basis for refactor-ings [Fow99]. Refactorings are transformations performed in code aiming at improving itsstructure. In most cases they are defined informally, which can lead to transformationsthat do not maintain the expected behavior. It has been shown that algebraic laws canbe successfully used in this context [Cor04, GM05], as they can be composed to provemore complex transformations.

Another new trend that has fruitfully used algebraic laws is the model-driven archi-tecture (MDD) [KWB03, OMG04]. It is based on models and transformations performedbetween different levels of models. These transformations can be specified and verified us-ing algebraic laws, as in [RSM06, Mas07], to assure that newly generated models maintainthe expected behavior from their originating models.

In this work, we use algebraic laws to transform Java programs, while preserving theirobservable semantics (behavior), but introducing new properties (parallelism).

2.3 PROGRAM PARALLELIZATION

Parallel systems are a major field in Computer Science. They have been studied inten-sively, and diverse techniques have been created to cope with the challenges that arisewhen developing these kind of systems. Their main characteristic is having multiplethreads of control, whereas sequential programs have only one. The different threadsof control work together by communicating to each other. The communication betweenthem is implemented by shared variables or message passing.

2.3 PROGRAM PARALLELIZATION 11

Another important point is how parallel systems are programmed. Concerning thisaspect, they can be classified as:

Explicit parallelism: the developer himself defines how the parallel execution will beperformed, providing each necessary synchronization and execution details.

Implicit parallelism: the developer does not manipulate low level parallelism con-structs while writing his code. It can, however, indicate which points of the codeare candidates to be parallelized.

It is well accepted that explicit parallelism can be used in more situations, presentsbetter speedups, as well as it yields systems that are better structured. Its major draw-back, however, is the effort needed to develop them, as well as the high risk of introducingbugs due to issues particular to parallel systems (such as non-determinism, deadlocks,and race conditions). On the other hand, the idea of implicit parallelism is to hide thedetails from the developer, leaving the responsibility of managing it to some compiler orruntime engine. Having these issues in mind, Whu et al [mHRU+07] argues that explicitparallelism is counterproductive in the long run, while implicit parallelism is the tech-nology of choice for the forthcoming many core processors. We agree up to some extentwith them. Programming explicitly for many processors is a hard task for the averageprogrammer, and having implicit mechanisms to hide the parallelism complexity is aninterest way to build parallel systems more efficiently. We believe, however, that someclasses of system require human intervention to be implemented, and are not adequateto implicit models.

Moreover, the parallelization can be automatic or manual. When an automatic paral-lelization is used, some engine detects where parallelism can be introduced and changesthe code or its execution. Its manual counterpart, however, relies on the developer toidentify the point where parallelism can be exploited.

According to Lea [Lea99], parallel programs can be divided into two categories, ac-cording to their nature:

Task-based: Parallelism is used to asynchronously invoke a method that performs sometask. The task might range from a single method to an entire session. Paral-lel techniques can support message-passing schemes that escape the limitations ofpure procedural calls. Task-based designs are seen in event frameworks, parallelcomputation, and IO-intensive systems.

Agent-based: Parallelism is used to create and set into motion a new autonomous,active, process-like object. This object may in turn react to external events, interactwith other actors, and so on. Actor-based designs are seen in reactive, control,and distributed systems. They are also the focus of most formal approaches toconcurrency.

Program parallelization is focused mostly on task-based parallel systems, becauseprograms that fit into this scenario are more amenable to systematic parallelization.

12 BACKGROUND

Agent-based systems usually present more complex behaviors that need more humanintervention to be expressed in a parallel fashion.

In the task-based category, parallel computing, which is focused on solving a largeproblem faster than it could be done sequentially, is a domain that has concentrated astrong research effort. This is the kind of computation usually needed by the scientificcomputing community, one of the main responsibles for the recent advances in programparallelization. Nevertheless, most of their tools and methods are focused on niche lan-guages such as Fortran [MR90]. In the end of the 90s, some effort has begun to bringsome of these techniques to Java, after being proved that it could deliver execution timescomparable with those provided by other languages [MMG00].

In order to parallelize tasks, there must be some degree of independence betweenthem. Strongly tangled tasks cannot be executed concurrently, since one must finishbefore the next one begins. As stated in [And00], parallel computing can present twodifferent types of parallelism:

Data parallelism - the same operations are performed in partitions of the data. Thisis usually performed when there are large amounts of data to be processed, and tospeed up their processing, the data is divided to many working threads that willexecute the same tasks in different parts of the data. This category has been thefocus of supercomputing for many years, and the techniques to take advantage ofit are better established than its task counterpart.

Task parallelism - distinct operations are performed in parallel. This can happen whenthere are independent tasks to be performed on the same data, or even in nonrelated data. One can have, for instance, different threads reading the same dataand compute different calculations. The most common form of task parallelismis called pipelining. It is done by inputting data successively to different workingthreads.

It is usually easier to parallelize systems that present data parallelism, since one needsonly to divide the data into partitions and distribute them to working threads. Scientificand technical computing are typical examples of domains which present strong dataparallelism, because they manipulate huge amounts of data. Task parallelism can be moredifficult, because determining dependencies between tasks is often more complicated.Nevertheless, it is more pervasive in computing, but frequently it is not worth parallelizingan individual task or small groups of them, due to the overhead incurred in a parallelexecution.

A very promising work on developing a modern programming language focused onparallelism and scientific computing is Fortress [Ste05, ACH+07]. It provides models forseamlessly exploring implicit parallelism, as well as a notation that resembles mathemat-ical formulae. Moreover, it presents features like object orientation and parametric poly-morphism, which are not usually present in traditional scientific computing languages.

2.3 PROGRAM PARALLELIZATION 13

2.3.1 Dependence Analysis

Program parallelization relies heavily on the notion of data independence [BENP93,Wol95, PK03]. In order to execute commands in parallel, there must be no couplingbetween them, because each one will have its own execution flow. In most cases, thesedependencies are determined by the data accessed by each command. Dependence anal-ysis is a field with a strong ongoing research; its advances were very important to thedevelopment of compiler theory and program parallelization. Take as an example thefollowing code:

(1) A = 0

(2) B = A

(3) C = A + D

(4) D = 2

Statement 2 cannot be executed before 1, since it could get an old value of A. Likewise,executing 4 before 3, would make 3 use the wrong value of D. It is clear that there aredependencies between the statements, and they impose an ordering on their execution.This same ordering prevents them from being executed in parallel, since the statementscannot execute simultaneously.

Dependence analysis can be performed statically or dynamically. Static analysis isperformed in compile time and is often called conservative, because when some depen-dencies cannot be determined statically, it assumes that the dependency exists. Dynamicanalysis, on the other hand, can use runtime information to discover whether dependen-cies exist, being capable therefore to determine them in more cases. More recently, hybridapproaches have also been developed [RRH03], which try to combine both analyses.

Static dependence analysis, however, has the advantages of posing a lighter overhead,and being easier to implement. Dynamic analysis, on the other hand, yields a heav-ier overhead, since it must perform a comprehensive set of execution flows in order todetermine any property.

Several dependence analysis algorithms have been developed, the one proposed byBanerjee [Ban88], I-Test [PKK93], and Omega test [Pug91] are among the most importantones in the literature. The problem of determining dependencies is typically reduced tosolving a linear system of equation and inequations, in this sense, the Banerjee test wasthe first one proposed. It can discover whether no dependence exists, but in some casesit fails to do so, even when there are no dependencies. The I-Test is an improvement overthe Banerjee test, being capable of disproving dependencies where its counterpart is not.The Omega test, in its turn, is more powerful than both of them, being able to produceexact yes/no answers, but it delivers worst case exponential complexity.

More recently, new techniques have been devised, such as [KP05], that have improvedprevious approaches, and overcame some of their limitations. Nevertheless, dependenceanalysis remains a challenge, even more when applied to modern object oriented pro-gramming languages.

14 BACKGROUND

2.4 FINAL CONSIDERATIONS

This chapter briefly presented the essential concepts involved in this thesis. We havedescribed the main features of Java, the target of our proposed transformations, focusingon its concurrency support. After that, we provided an overview about algebraic laws,the approach we adapt, highlighting their utility and how it has been used for diverse pur-poses. Finally, we presented some important concepts involved in program parallelization,the goal of our approach, describing different types of parallelism which can be detectedin existing systems, as well as the strong relation between program parallelization anddependence analysis.

CHAPTER 3

NORMAL FORM REDUCTION

2 is not equal to 3, not even for large values of 2.

—GRABEL’S LAW

Inspired by the laws of ROOL (an object oriented language with copy semantics) [BSCC04,SB06], this chapter presents laws for a significant subset of Java [GJSB05], consideringJava’s concrete syntax and the provisos for laws. Some entirely new laws were intro-duced, as laws involving constructors and static methods, which were not consideredbefore. Aiming at covering a broader range of applications, a strategy to cope with opensystems is presented and incorporated into the laws. We also show a reduction strategy totransform Java programs into a normal form, expressed in a small subset of Java features.This allows us to establish relative completeness of the set of laws.

3.1 OPEN SYSTEMS

Addressing open systems is a fundamental issue in our approach. Java is well known tohave an extensive set of built-in libraries; not dealing with them would exclude most Javasystems as targets for our transformations. Moreover, every Java class extends directlyor indirectly from Object, implying that there are no closed systems in Java. Mostimportantly, open systems can reference classes without having access to their sourcecode, or there can be other modules that depend on their code. In these cases, changingthe interface of the system can affect other modules.

By further investigating this issue, we noticed that we can divide open systems intotwo categories: general open systems (Figure 3.1), and limited open systems (Figure 3.2).General open systems can depend on other systems, as well as other systems can dependon them. Limited open systems can only depend on external elements; no externalelements depend on them. Our focus is on limited open systems, which is enough toexplore fine grained parallelism while using third-party code. From now on we refer tothis category simply as open systems, leaving the qualifier “limited” implicit.

The main idea is to change only the accessible source code, ignoring external (andtherefore preserving) elements in the transformations. Each law affects specific codeconstructs, whilst leaving the remaining code unchanged; only the affected constructsmust be accessible when performing transformations.

It is important, then, to precisely identify what belongs to the accessible system andwhat comes from external libraries. We define the set of class declarations that composethe entire system as follows:

cds = cdsinternal ∪ cdsexternal

names(cdsinternal) ∩ names(cdsexternal) = ∅

15

16 NORMAL FORM REDUCTION

Figure 3.1 General open system Figure 3.2 Limited open system

where cdsinternal is the set of class declarations with accessible source code (that can bechanged), and cdsexternal is the set of class declarations that come from third-party binarycode. Moreover, they are disjoint sets: no class declaration can belong to both sets. Tocapture this property we used the function names() to capture the name of the classdeclaration, avoiding repeated names. To enable the application of the laws in an opensystem context, we add new provisos to specify which elements must belong to cdsinternal

for the laws to hold.

When working with open systems, external classes are usually imported from theirpackages. Laws involved in this context would also need to address the import clausespresent in the code, as transformations could possibly move elements to different classes.We have chosen to ignore this issue, since we can eliminate all import clauses if we usethe complete (qualified) name of each class.

After dividing open systems into these two categories, we have then observed that theexisting laws could be easily used for limited open systems. We have simply interpretedthe laws considering the presence of external elements, instead of only internal elements,as the closed system hypothesis assumes.

3.2 LAWS

Transformation laws are usually presented in an equational style with left and right handsides. For each equation, there might be a set of conditions that must be fulfilled toperform the transformation in each direction. Most of our laws are context dependent,as expected for an object-oriented program.

The laws are written in Java, representing the equivalence between two different piecesof well typed code. Our aim is to address the complete syntax of Java, but currently weexclude the following features: new features of Java 1.5, exceptions, threads, synchro-nization, and interfaces. We also adopt the convention that a Java system has the formcds Main, where cds is a set of class declarations and Main is a class with the only mainmethod present in the system. We also consider that all internal class declarations arein the default package.

3.2 LAWS 17

One important point to discuss concerning our laws is the notion of equality we adopt.We consider two complete Java systems of the form cds1 Main1 = cds2 Main2 equivalentwhen they present the same observable behavior. Some semantics have been proposedfor Java as, for example, [AF99], and can be used to formalize this equality relation.Nevertheless, to present our laws, it is convenient to focus only on the elements affected bythe laws, like two class declarations cd1 and cd2; thus, we use the notation cd1 =cds,Main cd2

to capture the context for the law, as an abbreviation of cd1 cds Main = cd2 cds Main. Itis also worth mentioning that in our laws, cds represents the entire set of class declarations,including the external ones.

We present laws in three sections according to the constructs they affect. Some lawsare adapted from [SB06], which presents laws for ROOL, an object-oriented language withcopy semantics. For these laws, we emphasize the conditions for them to hold in Java,which were not present in the laws defined for ROOL. To our knowledge, the remaininglaws are entirely new. An overview of the proposed laws and how they were defined ispresented in Section 3.2.6.

The conditions required in each law obey the following convention. Conditions markedwith (↔) must hold when performing the transformation in both directions; conditionsmarked with (→) must hold when performing the transformation from left to right, andthose with (←) from right to left.

3.2.1 Classes

Hereafter we use: ads, cnds, and mds to represent attributes, constructors, and methodsdeclarations, respectively; T represents a type. The symbol ≤ represents the subtyperelation between classes. To simplify the conditions, we will consider that the classeswhose declarations are explicit belong to the internal class set.

We can eliminate a class declaration if it is not used anywhere in the program. Con-versely, we can introduce a new class declaration if it is not already present, and if it hasa valid superclass.

Law 1. 〈class elimination/introduction〉

cds cd1 Main = cds Main

provided

(→) The class declared in cd1 is not referred in cds or Main;

(←) (1) The name of the class declared in cd1 is distinct from those of all classes declaredin cds;(2) the superclass appearing in cd1 is either Object or declared in cds.

2

We must also consider Object as a valid class, because it is the default superclass forJava classes. It is worth noting that this law holds even when cd1 is a external class, astheir definitions can be also removed and introduced.


In the following law, the notation B.a refers to uses of the name a via expressionswhose static type is exactly B, as opposed to any of its subclasses. For example, if wewrite that B.a does not appear in mds, we mean that the bodies of the methods in mdsdoes not contain any expression such as e.a, for any e of type B, strictly.

Law 2. 〈change superclass: from Object to another class〉

class C extends Object {adscndsmds

}

=cds,Main

class C extends B {adscndsmds

}

provided

(←) (1) C or any of its subclasses in cds, cnds, and mds is not used in type casts ortests involving any expression of type B or of any supertype of B;(2) There are no assignments of the form le = exp, for any le whose declared typeis B or any superclass of B and any exp whose type is C or any subclass of C;(3) Expressions of type C or of any subclass of C are not used as arguments in callswith a corresponding formal parameter whose type is B or any superclass of B;(4) Expressions whose declared type is B or any of its superclasses are not returnedas a method result in calls with an expected result whose declared type is C or anysubclass of C;(5) this.a does not appear in C, nor in any subclass of C, for any public or protectedattribute a of B or of any of its superclasses;(6) le.a, for any le : C, does not appear in cds or c for public attribute a of B or ofany of its superclasses;(7) There is no D.m, for any m and D such that m is declared in B or in any of itssuperclasses, but not in mds, and D ≤ C;(8) super does not appear in any method in mds.

2

It is important to mention that on the right-hand side of the law, Object continuesto be C’s superclass, but indirectly. When changing the superclass to Object, there isa much larger set of provisos, because C will no longer be a subclass of B, not evenindirectly.

3.2.2 Attributes

The subsequent laws involve the variations on how attributes can be declared and theirequivalences. For the following visibility laws, it is important to emphasize that we areconsidering that all accessible code is in the same package.

3.2 LAWS 19

Law 3. 〈change attribute visibility: from default to public〉

class C extends D {T a; adscndsmds

}

=cds,Main

class C extends D {public T a; adscndsmds

}

2

Law 4. 〈change attribute visibility: from protected to public〉

class C extends D {protected T a; adscndsmds

}

=cds,Main


}

2

Law 5. 〈change attribute visibility: from private to public〉

class C extends D {private T a; adscndsmds

}

=cds,Main


}

provided

(←) B.a, for any B ≤ C, appears only in C’s body

2

Laws to change the visibility of attributes are rather similar. Changing the visibilityto a less restrict one is always possible, but the opposite must respect the specific condi-tions of each visibility modifier.

The next law shows when it is possible to move an attribute to a super or subclass,by applying the transformation from left to right and from right to left, respectively.


Law 6. 〈move attribute to superclass〉

class B extends A {adscndsmds

}class C extends B {

public T a; ads′

cnds′

mds′

}

=cds,Main

class B extends A {public T a; adscndsmds

}class C extends B {ads′

cnds′

mds′

}

provided

(→) The attribute name a is not declared in ads;

(←) (1) The attribute name a is not declared in ads’; (2) D.a, for any D ≤ B and D �C, does not appear in cds, Main, cnds, cnds’, mds, or mds’.

2

The type of an attribute can be changed to any other related type in its class hierarchy,if the provisos hold. This law does not take in consideration primitive types, because thesubtype relation ≤ is defined only for classes. In the following law we consider a assignableoccurrence, when an attribute or variable is in the left side of a expression. Thus, theremaining occurrences are non-assignable.

Law 7. 〈change attribute type〉


}

=cds,Main

class C extends D {public T ′ a; adscndsmds

}

provided

(↔) T ≤ T ′ and every non-assignable occurrence of a in expressions of mds, cds andMain is cast with T or any subtype of T declared in cds.

(←) every expression assigned to a, in mds, cds and c, is of type T or any subtype of T;

2

3.2 LAWS 21

3.2.3 Methods

The following laws concern methods, both their declarations and calls. In the followinglaws, m is the name of the method, rt is its return type, mbody is its body, and pds isits declared list of parameters.

Law 8. 〈change method visibility: from default to public〉

class C extends D {adscndsrt m(pds){mbody}mds

}

=cds,Main

class C extends D {adscndspublic rt m(pds){mbody}mds

}

2

Law 9. 〈change method visibility: from protected to public〉

class C extends D {adscndsprotected rt m(pds){mbody}mds

}

=cds,Main


}

2

Law 10. 〈change method visibility: from private to public〉

class C extends D {adscndsprivate rt m(pds){mbody}mds

}

=cds,Main


}

provided

(←) B.m(), for any B ≤ C, appears only in C’s body.


2

These laws are very similar to the laws to change the visibility of attributes, as thevisibility modifiers have the same semantics for both of attributes and methods. It isalso important to mention that Laws 8 and 9 do not have any conditions because we areconsidering that the internal classes are in the same package.

Law 11. 〈introduce void method redefinition〉

class B extends A {adscndsvoid m(pds) {mbody}mds


cnds′

mds′

}

=cds,Main



cnds′

void m(pds) {super.m(α(pds));

}mds′

}provided

(→) m(pds) is not abstract and it is not declared in mds’.

2

This law introduces a trivial redefinition of a superclass method, inserting a call tothe original method in its body. α(pds) is the list of identifiers of the formal parameters.The adaptation of this law from ROOL to Java had to consider the possibility of methodoverloading, by using the complete method signature as its identifier, not just its name.

Law 12. 〈introduce non void method redefinition〉

3.2 LAWS 23

class B extends A {adscndsrt m(pds) {mbody}mds


cnds′

mds′

}

=cds,Main



cnds′

rt m(pds) {return super.m(α(pds));

}mds′

}provided

(→) m(pds) is not abstract and it is not declared in mds’.

2

The law above is very similar to Law 11, but it requires the introduction of the returnclause, since the method must yield the result of executing super.m(α(pds)).

Law 13. 〈move redefined method to superclass〉



cnds′

rt m(pds) {mbody′}mds′

}

=cds,Main

class B extends Aadscndsrt m(pds) {

if(! this instanceof C){mbody} else {mbody′}

}mds


cnds′

mds′

}

provided

(↔) (1) super and private attributes do not appear in mbody′; (2) super.m(pds) doesnot appear in mds′.


(→) mbody′ does not contain uncast occurrences of this nor expressions of the form((C)this).a for any protected attribute a in ads′.

(←) m(pds) is not declared in mds′.

2

In the law above, we eliminate a method redefinition by moving its body to the su-perclass. The original method body is modified to test the object type before choosingwhich body to execute, as a means to simulate dynamic binding.

Law 14. 〈move original method to superclass〉

class B extends A {adscndsmds


cnds′

rt m(pds) {mbody}mds′

}

=cds,Main



cnds′

mds′

}

provided

(↔) (1) super and private attributes do not appear in mbody; (2) m(pds) is not declaredin any subclass of B in cds; (3) m(pds) is not private.

(→) (1) m(pds) is not declared in mds; (2) mbody does not contain uncast occurrences ofthis nor expressions in the form ((C)this).a for any protected attribute a in ads′.

(←) (1) m(pds) is not declared in mds′; (2) D.m(e), for any D ≤ B and D 6≤ C, doesnot appear in cds,Main, mds or mds′.

2

Methods can be moved up to a superclass, since they will be inherited by their originalowner classes. This transformation can be useful to allow calling a method in a broaderrange of objects.

3.2 LAWS 25

Law 15. 〈change parameter type〉

class C extends D {adscndsrt m(T x, pds) {mbody}mds

}

=cds,Main

class C extends D {adscndsrt m(T ′ x, pds) {mbody}mds

}

provided

(↔) T ≤ T ′ and every non-assignable occurrence of x in expressions of mbody are castwith T or any subtype of T .

(←) (1) every actual parameter associated with x in mds, cds and Main is of type T orany subtype of it; (2) every expression assigned to x in mbody is of type T or anysubtype of T ; (3) every use of x as the method return in mbody is for a correspondingdeclared return of type T or any supertype of T .

2

It is possible to change the type of a parameter, if the new type is related to the originalone by a typing hierarchy. When changing to a supertype, casts are needed where thesubtype was expected; when changing to a subtype, the restrictions are stronger, requiringevery actual parameter to be compatible with the new type. In the following law, returntypes can be changed in a similar way.

Law 16. 〈change return type〉

class C extends D {adscndsrt m(pds) {mbody}mds

}

=cds,Main

class C extends D {adscndsrt′ m(pds) {mbody}mds

}

provided

(↔) rt ≤ rt′

(→) every call to m(pds) used as a expression is cast to rt.

(←) every expression used in return clauses in mbody is of type rt or of any subtype ofrt.

2


In the following law, [result = val/return val] means that every occurrence ofreturn val inside the method body is replaced by result = val.

Law 17. 〈eliminate multiple return points〉

class C extends D {adscndsrt m(pds) {mbody

}mds

}

=cds,Main

class C extends D {adscndsrt m(pds) {rt result;mbody

[result = val/return val]return result;

}mds

}

provided

(→) (1) the variable result is not already declared in mbody; (2) return clauses arepresent only inside mutually exclusive paths.

2

Given some conditions, multiple return points can be eliminated by declaring a returnvariable, changing its value in the previous return locations, and returning the variablein the last line of the method. We can only eliminate them if they are not used to controlthe execution flow, this is captured by the condition that requires the return clauses to beinside mutually exclusive paths. If they are used to break loops, for instance, we cannoteliminate them, since it would change the original behavior of the method.

Law 18. 〈method elimination/introduction〉

class C extends D {adsrt m(pds) {mbody}cndsmds

}

=cds,Main

class C extends D {adscndsmds

}

provided

(→) B.m(e) does not appear in cds,Main nor in cnds,mds, for any B such that B ≤ C.

(←) m(pds) is not declared in mds nor in any superclass or subclass of C in cds.

3.2 LAWS 27

2

It is possible to remove a method declaration if it is not used. Methods that are notcalled anywhere else are often useless, and can be therefore eliminated. To introduce anew method declaration, it suffices that no other method exists in mds with the samesignature.

In the next law, we use the notation cds CDS,N B c = d. In this notation, cds CDS,Cis the union of the class declarations in cds and CDS, and cds,N B c = d indicates thatthe equation c = d holds inside the class named N , in the context defined by the set ofclass declarations cds. The function vardecs(pds, e) introduces a set of variables whichhave the same names and types of the formal parameters pds, and are initialized withthe arguments used to call the method. Consider the following example:

pds = (int a, String s)e = (100, “ABC”)vardecs(pds, e)⇒ int a = 100; String s = “ABC”;

In this way we can capture the call by value mechanism of Java. Using this function,we can replace a method call by its body, as in the following law, which targets calls tomethods via super.

Law 19. 〈eliminate calls to void methods via super〉Consider that CDS is a set of two class declarations as follows.


}

class C extends B {ads′

cnds′

mds′

}

Then we have that

cdsCDS,C B super.m(e) = vardecs(pds, e);mbody

provided

(→) (1) super, this, and the private attributes in ads do not appear in mbody; (2)mbody does not contain return clauses.

2

Eliminating calls to void methods require only replacing their call by their body,since both are commands. When the method is not void, it can be used as an expression,preventing a simple replacement for its body. To address calls to methods via super inthis case, we have devised the following law.


Law 20. 〈eliminate calls to non void methods via super〉Consider that CDS is a set of two class declarations as follows.


}

class C extends B {ads′

cnds′

mds′

}

is included in cds. Then cdsCDS,C B

rt a = super.m(e) =

rt a;vardecs(pds, e);mbody[a = result/return result]

provided

(→) (1) super, this, and the private attributes in ads do not appear in mbody; (2)m(pds) does not have multiple return points.

2

It is important to remark that we consider only one possible context for the methodcall, which is using it as right side expression in an assignment. Addressing every possibleoccurrence of a method call could complicate the law, and as we have laws to convertother occurrences to this form, this law can be applied in most cases.

Law 21. 〈void method call elimination〉Consider that the following class declaration

class C extends Dadscndsvoid m(pds) {mbody}mds

}is included in cds, and that cds, A B le : C, meaning that le has static type C in class A.Then

cds, A B le.m(e) = assert le ! = null; vardecs(pds, e);mbody[le/this]

provided

(→) (1) m(pds) is not redefined in cds and mbody does not contain references to super;(2) all attributes which appear in mbody of m(pds) are not private; (3) C’s methodscalled within mbody are not private; (4) mbody does not contain recursive calls;(5) pds does not occur in e; (6) mbody does not contain return clauses; (7) attributesand methods of C within mbody are preceded by this.

3.2 LAWS 29

2

Once there is no redefinition of methods, it is possible to copy its body where it is called,after performing some parameter substitution. In the above law, the method call le.m(e)might throw an exception when le is null. This is captured on the right-hand side by theassertion statement.

We can only eliminate method calls to non-recursive methods. In ROOL, there arerecursive commands, then one could easily rewrite a recursive method as a recursivecommand and inline it, but in Java there is no such a feature. Nevertheless, we canget close to an imperative program by transforming a method into a static method, ascaptured by Law 24.

Eliminating non void calls requires different laws, since calls of this type can be usedas expressions, and contain return clauses inside their body. The following laws addressthis case.

Law 22. 〈non void method call elimination - when used as an expression〉Consider that the following class declaration

class C extends Dadscndsrt m(pds) {mbody}mds

}is included in cds, and that cds, A B le : C. Then

rt a = le.m(e) =

rt a;assert le ! = null;vardecs(pds, e);mbody[le/this][a = result/return result]

provided

(↔) (1) m(pds) is not redefined in cds and mbody does not contain references to super;(2) all attributes which appear in mbody of m(pds) are public; (3) mbody does notcontain recursive calls; (4) pds does not occur in e.

(→) (1) m(pds) does not have multiple return points; (2) attributes and methods of Cwithin mbody are preceded by this.

2

Law 23. 〈non void method call elimination - when used as a statement〉Consider that the following class declaration



}is included in cds, and that cds, A B le : C. Then

le.m(e) =

assert le ! = null;vardecs(pds, e);mbody[le/this][skip/return val]

provided

(→) (1) m(pds) is not redefined in cds and mbody does not contain references to super;(2) all attributes which appear in mbody of m(pds) are public; (3) mbody does notcontain recursive calls; (4) pds does not occur in e; (5) attributes and methods ofC within mbody are preceded by this.

2

When eliminating non-void method calls used as statements, its return value can beignored. It is done by removing the return clause from its body, replacing it by skip(syntactic sugar used to represent an empty command).

Law 24. 〈Make method static〉

class C extends D {adsrt m(pds) {mbody}cndsmds

}cds,Main

=

class C extends D {adsstatic rt m(C c, pds) {mbody[c/this]

}cnds′

mds′

}cds′,Main′

where, given o of type C:

cnds′ = cnds[C.m(o, e)/o.m(e)]mds′ = mds[C.m(o, e)/o.m(e)]cds′ = cds[C.m(o, e)/o.m(e)]Main′ = Main[C.m(o, e)/o.m(e)]

3.2 LAWS 31

provided

(↔) (1) there are no references to super in mbody; (2) there are no redefinitions ofm(pds); (3) attributes and methods of C within mbody are preceded by this.

2

This law is more complicated than the ones presented before. The main reason isthat it changes the code in the method definition, as well as in every occasion the originalmethod is called. To convert an instance method into a static method, the object whereit is called is now passed as a parameter and references to this inside mbody are replacedby the formal parameter identifier. After changing the method signature, every call too.m(αpds) is converted to a call to C.m(o, αpds). It is also worth mentioning that theoriginal call is converted into a static call.


Law 25. 〈move static method to another class〉

class B extends A {adsbcndsbstatic rt m(pds) {mbody}mdsb

}class C extends D {adsccndscmdsc

}cdsMain

=

class B extends A {adsbcndsb

′

mdsb′

}class C extends D {adsccndsc

′

static rt m(pds) {mbody}mdsc

′

}cds′

Main′

where :

cndsb′ = cndsb[B.m(e)/C.m(e)]

mdsb′ = mdsb[B.m(e)/C.m(e)]

cndsc′ = cndsc[B.m(e)/C.m(e)]

mdsc′ = mdsc[B.m(e)/C.m(e)]

cds′ = cds[B.m(e)/C.m(e)]Main′ = Main[B.m(e)/C.m(e)]

provided

(↔) (1) static attributes and methods are accessed by the class name in mbody; (2)attributes accessed in mbody are public;

(→) m(pds) is not declared in mdsc;

(←) m(pds) is not declared in mdsb;

2

A static method can be moved to another class, once its body only accesses memberswhich are visible in the class to which it is moved.

3.2.4 Constructors

This subsection presents the laws for constructors. They are an important contributionof this work, since, to our knowledge, there is not a comprehensive set of laws definedfor constructors in object-oriented languages, and particularly in Java. For instance,

3.2 LAWS 33

ROOL [SB06] has a very limited form of constructor, and laws for this feature are notdeeply explored. The set laws devised for Java is presented in the sequel.

Law 26. 〈introduce empty default public constructor〉


}

=cds,Main

class C extends B {adspublic C() {}cndsmds

}

provided

(→) a default constructor is not already defined in C.

2

The law depicted above shows when it is possible to introduce or remove a defaultconstructor. When a class does not define any constructor, a default constructor isautomatically inserted by the compiler.

Law 27. 〈eliminate calls to super() inside constructors〉

class C extends B {adsC(pds) {

super();cbody

}cndsmds

}

=cds,Main

class C extends B {adsC(pds) {cbody

}cndsmds

}

provided

(←) cbody does not contain any call to a super constructor.

2

Removing calls to super() is very useful to later on inline the constructor body, aspresented in Law 31. A subtle fact about this law is that Java compilers automaticallyinsert the super() call in the constructor first line, when no other constructor is explicitlycalled. This is the reason why both pieces of code are equivalent; it is just a matter ofchoosing to keep the call explicit or implicit.


Law 28. 〈eliminate calls to super(α(pds))〉

class B extends A {adsB(pds) {cbody}cndsmds


C(pds) {super(α(pds));cbody′

}cnds′

mds′

}

=cds,Main

class B extends A {adsB(pds) {cbody}cndsmds


C(pds) {cbodycbody′

}cnds′

mds′

}

provided

(→) (1) cbody does not contain calls to super; (2) B contains an empty default construc-tor; (3) all attributes which appear in cbody of B(pds) are public;

(←) B has a non private constructor B(pds), whose body is cbody.

2

The next law is similar to the previous one, but instead of eliminating calls to the defaultsuper constructor, it eliminates calls to the non-default ones. In this case, we have tocopy the super constructor body where it was called. No substitution of names wereneeded, since both constructors have the same formal parameters pds. There is also asimilar law to eliminate calls to this().

3.2 LAWS 35

Law 29. 〈eliminate calls to this(e)〉

class C extends B {adsC(pds){cbody

}C (pds′){this(e);cbody′

}cndsmds

}

=cds,Main

class C extends B {adsC(pds){cbody

}C(pds′){vardecs(pds, e)cbodycbody′

}cndsmds

}

provided

(↔) e matches pds;

(→) (1) cbody does not contain calls to this(); (2) cbody’ does not contain calls to super.

2

The above law holds for default or non-default constructors. When a call to a defaultconstructor is eliminated, we need only to copy its body inside the callee constructorbody, since, in this case, pds is empty. To assure that e corresponds to pds, one conditionwas introduced, as there can be multiple constructors defined with parameters.

Law 30. 〈eliminate non-default constructors〉

class C extends B {adsC(pds) {cbody}cndsmds

}

=cds,Main


}

provided

(→) There are no calls to new C(pds) in ads, cnds, mds, cds, and Main (including callsvia super or this);

(←) C(pds) is not already declared in C.

2


This law is similar to the elimination of methods. It removes the constructor definitionwhen there are no calls to it, a means of eliminating unnecessary code. It can also beused to introduce new constructors.

Law 31. 〈eliminate calls to non-default constructors〉Consider that the following class declaration

class C extends DadsC(pds) {cbody}cndsmds

}

is included in cds, and that cds, A B C le. Then

C le = new C(e); =cds,MainC le = new C();vardecs(pds, e); cbody[le/this]

provided

(→) (1) C has an empty default constructor;(2) there are no calls to super or this() incbody; (3) pds does not occur in e; (4) attributes and methods of C within cbody arepreceded by this; (5) all attributes which appear in cbody are not private; (6) C’smethods called within cbody are not private.

2

Calls to constructors can be eliminated in a similar way it was done to methods. Themain difference is that we cannot completely eliminate it, since calling the constructoris mandatory to object creation. Our strategy is to keep a call to an empty default con-structor, and then execute the commands to initialize the object attributes, maintainingthe original constructor behavior. The next law addresses the same issue for defaultconstructors.

Law 32. 〈inline default constructor calls and eliminate its body〉

class C extends B {adsC() {cbody}cndsmds

}cdsMain

=

class C extends B {adsC() {}cnds′

mds′

}cds′

Main′

3.2 LAWS 37

where

cnds′ = cnds[C c = newC(); cbody[c/this]/C c = newC()]mds′ = mds[C c = newC(); cbody[c/this]/C c = newC()]cds′ = cds[C c = newC(); cbody[c/this]/C c = newC()]Main′ = Main[C c = newC(); cbody[c/this]/C c = newC()]

provided

(→) (1) cbody does not contain references to super nor calls to this(); (2) attributesand methods of C within cbody are preceded by this; (3) all attributes which appearin cbody are not private; (4) C’s methods called within cbody are not private.

2

Law 33. 〈change constructor visibility: from private to public〉

class C extends D {adsprivate C(pds) {cbody}cndsmds

}

=cds,Main

class C extends D {adspublic C(pds) {cbody}cndsmds

}

provided

(←) calls to new C() appears only in C’s body

2

Law 34. 〈change constructor visibility: from protected to public〉

class C extends D {adsprotected C(pds) {cbody}cndsmds

}

=cds,Main


}

2


Law 35. 〈change constructor visibility: from default to public〉

class C extends D {adsC(pds) {cbody}cndsmds

}

=cds,Main


}

2

Changing the visibility of constructors works very similarly to changing the visibilityof methods, as can be noticed by the resemblance of their conditions.

3.2.5 Commands and Expressions

In contrast to the previous laws, which were focused on changing the structure of thesystem, the subsequent laws are focused in finer grained elements: commands and ex-pressions. They are usually present inside the body of methods and constructors, andlaws affecting them have a lesser impact in the system as a whole.

Law 36. 〈eliminate cast of method call〉If cds, A B e : B, C ≤ B and m is declared in B or in any of its superclasses in cds, then

cds, A B ((C)e).m(e′) = assert(e instanceof C); e.m(e′)

2

When a method defined in a superclass is called, there is no need to cast the objectto a subclass.

Law 37. 〈change variable type〉

cds, A B T x; c = T ′ x; c

provided

(↔) T ≤ T ′ and every non-assignable occurrence of x in expressions of c is cast with Tor any subtype of T ;

(←) (1) every expression assigned to x in c is of type T or any subtype of T ; (2) every useof x as the return expression in c is for a corresponding declared return of type T orany supertype of T ; (3) every use of x as an argument in c is for a correspondingdeclared parameter of type T or any supertype of T .

3.2 LAWS 39

2

The types of variables can be changed follwing similar conditions to changing the typeof attributes (Law 7).

Law 38. 〈introduce trivial cast in expressions〉If cds, A B e : C, then

cds, A B e = (C) e

2

As stated by the law above, it is always possible to cast an object to its declared type.

Law 39. 〈eliminate cast of expressions〉If cds, A B le : B and cds, A B e : B′, with C ≤ B′ and B′ ≤ B, then

cds, A B le := (C) e = assert (e instanceof C); le := e

2

Casts can be removed when the left hand side of the assignment expects the type orsupertype from the expression on its right hand side.

Law 40. 〈eliminate/introduce this in attribute access〉Consider the following class declaration

class C extends DT att; adscndsmds

}then cds, C B att = this.att

provided

(→) att is not preceded by a dot operator (“.”);

(←) there are no variables or parameters called att in the method or constructor bodythere att is referenced.

2

Law 41. 〈eliminate/introduce this in method calls〉Consider the following class declaration



}then cds, C B m(e) = this.m(e)

provided

(→) m(e) is not preceded by a dot operator (“.”);

2

The keyword this can be inserted and eliminated when accessing attributes and callingmethods inside a class body. The exception is when there are parameters or variablesdefined with the same name of the attributes, in the same scope they are being referenced.

In the next law, Ct stands for the scope where the expression exp is being used. It isusually a method or constructor body, or conditionals and loops delimited with braces.

Law 42. 〈replace expression by variable〉Consider that cds,N B T exp, then cds,N B

Ct[exp] =ExpType tmp = exp;Ct[tmp/exp]

provided

(→) (1) tmp is not already declared in Ct; (2) variables used in exp are not assigned inCt; (3) exp occurs only once in Ct.

2

When using an expression in a determined context (Ct), inside N ’s body, we can storeits value in a variable, and use the variable where the expression was previously used.

Law 43. 〈add final modifier to local variable〉Consider that cds,N B T var, then

cds,N B Ct[T var; ] = Ct[final T var; ]

provided

(→) var has its value assigned only once in Ct

2

3.3 NORMAL FORM REDUCTION 41

The final modifier can be added to a local variable if the variable has its value changedonly once during its lifetime.

Law 44. 〈change variable scope〉

T var; Ct[{cmds}] = Ct[{T var; cmds}]

provided

(→) var is accessed only within Ct

2

When a variable is used only within some scope, it is possible to move its declarationinto that scope. In fact, this laws is derived from a more general one, that states thedistributivity of variable declarations. The more general laws have been defined by Hoareand Roscoe [HHJ+87, RH88], and work in a very similar way in Java. We therefore presentthe one that we are more interested in, which is enough to provide some insight on howit works in other contexts.

3.2.6 Summary of Laws

In this subsection we present the summary of the laws we presented, indicating how eachlaw was conceived. Concerning this latter aspect, we divide them into three categories:

Minor adaptation (∗) - laws easily adapted from ROOL, which required mostly syn-tactic adaptations.

Major adaptation (∗∗) - laws which required a major effort to be adapted, eventuallyleading to the creation of derived laws.

New law (∗ ∗ ∗) - transformations that, to our knowledge, have not been defined asalgebraic laws.

Table 3.1 depicts the summary of our laws.

3.3 NORMAL FORM REDUCTION

A standard approach to gaining confidence on the comprehensiveness of a set of algebraiclaws is providing a reduction strategy. It transforms a compliant program into a normalform, which includes only a small subset of the language constructs. The simpler thenormal form, the more expressive tend to be the set of laws. The first subsection belowdefines a normal form and the subsequent subsection presents a reduction strategy. Wefollow the approach proposed for ROOL in [SB06], with some adaptations for Java.


classes 1: class elimination/introduction ∗2: change superclass: from Object to another class ∗

attributes 3: change attribute visibility: from default to public ∗ ∗ ∗4: change attribute visibility: from protected to public ∗5: change attribute visibility: from private to public ∗6: move attribute to superclass ∗7: change attribute type ∗

methods 8: change method visibility: from default to public ∗ ∗ ∗9: change method visibility: from protected to public ∗ ∗ ∗10: change method visibility: from private to public ∗ ∗ ∗11: introduce void method redefinition ∗∗12: introduce non void method redefinition ∗∗13: move redefined method to superclass ∗14: move original method to superclass ∗15: change parameter type ∗16: change return type ∗∗17: eliminate multiple return points ∗ ∗ ∗18: method elimination/introduction ∗19: eliminate calls to void methods via super ∗∗20: eliminate calls to non void methods via super ∗∗21 void method call elimination ∗∗22: non void method call elimination (expression) ∗∗23: non void method call elimination (statement) ∗∗24: make method static ∗ ∗ ∗25: move static method to any class ∗ ∗ ∗

constructors 26: introduce empty default public constructor ∗ ∗ ∗27: eliminate calls to super() inside constructors ∗ ∗ ∗28: eliminate calls to super(α(pds)) ∗ ∗ ∗29: eliminate calls to this(e) ∗ ∗ ∗30: eliminate non-default constructors ∗ ∗ ∗31: eliminate calls to non-default constructors ∗ ∗ ∗32: inline default constructor calls and clean its body ∗ ∗ ∗33: change constructor visibility: from private to public ∗ ∗ ∗34: change constructor visibility: from protected to public ∗ ∗ ∗35: change constructor visibility: from default to public ∗ ∗ ∗

commands 36: eliminate cast of method call ∗and expressions 37: change variable type ∗

38: introduce trivial cast in expressions ∗39: eliminate cast of expressions ∗40: eliminate/introduce this in attribute access ∗ ∗ ∗41: eliminate/introduce this in method calls ∗ ∗ ∗42: replace expression by variable ∗ ∗ ∗43: introduce final modifier in variable declaration ∗ ∗ ∗44: change variable scope ∗

Table 3.1 Complete set of laws

3.3 NORMAL FORM REDUCTION 43

3.3.1 Normal Form

Our strategy transforms the original source code into a normal form that conforms to thefollowing conditions:

� Each class declaration in cdsinternal, except Object, has no attributes;

� Methods are allowed only in the Main class, and they must be static;

� There is a main method in the Main class;

� The Object class may include only attribute declarations, and their types must bea primitive type, or Object, or defined by an external class;

� All local declarations in the main method are declared with a primitive type, orObject, or an external class;

� No type cast is allowed in the main method;

� There are no declarations of constructors.

Basically, a program in normal form is similar to an imperative program, except thatwe keep the class hierarchy (only for the purpose of typing, since the classes do not declareattributes, methods or constructors). The class Object acts like a recursive record atthe root of the hierarchy, since we cannot modify the class Object, which belongs to theexternal class set. Only static methods (playing the role of procedures) are allowed, andrestricted to the Main class.

In our normal form, as we are working with limited open systems, the restrictionsapply only to the internal code, since it is the code we can change. This scenario allowsus to have only a partial normalization, in which the internal code complies to the normalform, and the external code remains unchanged.

3.3.2 Reduction Strategy

The reduction strategy we propose is based on the strategy presented in [SB06]. Somenew steps were needed due to some particularities of Java, such as constructors, but theexisting steps required just minor modifications. The strategy comprises a set of lawsthat must be applied in a defined order, in a way to make the application of a particularlaw enable the application of a subsequent law by making its preconditions hold. Themajor steps of our strategy are briefly presented in the sequel, focusing on the newlyintroduced steps. For a more detailed description, refer to [SB06].

Introduce new root class and move attributes to it The first transformationintroduces a new class, called Object (Law 1). Then we change the hierarchy of classes,to use Object as the new root superclass (Law 2). All classes that do not explicitlyextend another class, and therefore extend Object, will now extend Object. The naturalcandidate to represent the root of the hierarchy is the class Object, but in Java we cannot


modify it, since it belongs to the language standard library. Thus, the introduction of anew class is necessary. An exception to this rule is the Main class. It contains only themain method and some other static methods, working as the entry point to the executionof the program.

After introducing the new root superclass, every attribute has its visibility changedto public (Laws 3, 4, 5) and they are moved from subclass to superclass until they reachthe root superclass Object (Law 6).

Eliminate constructors Our goal is to eliminate all constructor declarations and calls,similarly to the elimination of methods (discussed in subsequent steps). Before eliminat-ing constructors, we use laws 40 and 41, in order to facilitate their future inlining. Everyconstructor declaration is eliminated (Law 30), after having their calls inlined, includingcalls via super and this (Laws 28, 29, 31).

Move methods up and change types to Object Every method declaration is movedto the root superclass Object. To do this, we must successively apply laws to changethe visibility of methods to public (Laws 8, 9, 10), and introduce trivial redefinitions(Law 11). After that, we eliminate calls to super methods using Laws 19, and 20, andintroduce trivial casts (Law 38).

After finishing these steps, we are able to move methods up until they reach the topsuperclass (Laws 13, 14). Another important transformation is changing the types toObject; this transformation is applied to attributes, variables, parameters and return

types, except those defined with primitive or external types (Laws 7, 15, 16, 37). Astypes are changed to Object, casts can be eliminated using Laws 39 and 36.

Eliminate instance methods Finally, every method call is inlined using the copy law(Laws 21, 22, 23), and the method declaration is eliminated (Law 18), except for recursivemethods. There are some approaches to eliminate recursive calls, such as [Tan06], butthey cannot completely eliminate recursion, or it can be rather cumbersome in somecases. We decided then to keep recursion, but restrict it to static methods in the Mainclass. Thus, we create a new static method with the same name as the original method,and with an extra parameter to provide the object where the method was previouslycalled (Law 24). This method is then moved to the Main class (Law 25). In this way,methods become procedures as in imperative languages. We use the same steps when amethod has multiple return points that cannot be eliminated. This situation preventsthe method from being inlined, and therefore it cannot have its definition removed.

3.4 CASE STUDY

This section illustrates the application of the reduction strategy to a simple expressioninterpreter written in Java. The system conforms to the restrictions of our strategy,but presents some important object-oriented features like inheritance, overriding andoverloading. This makes it a representative example to show the expressiveness of our

3.4 CASE STUDY 45

set of laws.

The interpreter was devised for a simple expression language called Exp1. This lan-guage supports the definition of two types of expressions: integer literals, and sums. Itsoriginal class diagram is depicted in Figure 3.3. Classes Expression, Value, Integer, Bina-ryExpression, and Sum represent the different types of expressions supported; Interpreterevaluates any expression yielding its resulting value; Main is the application entry point.

Figure 3.3 Exp1 interpreter (original class diagram)

The first step of our reduction strategy is introducing the new class Object. Itpresents no problem since there is not any class already defined with that name. Then wechange our inheritance hierarchy, making the Expression and Interpreter classes inheritfrom Object. After that, every attribute declaration is moved to Object.

The next step is reducing the constructors. The non-default constructor in classes In-terpreter, Integer, BinaryExpression, and Sum are eliminated. The updated class diagramcan be observed in Figure 3.4.

At this point, our aim is to move methods up to Object. After changing theirvisibility to public, and eliminating references to super in their bodies, they are movedup from the bottommost classes Interpreter, Sum, and Integer until they reach Object.Furthermore, we change the types of variables, attributes, parameters, and return typesto Object, this is possible since we have already moved all attributes and methods toObject. The resulting diagram is shown in Figure 3.5.

The final step to achieve the normal form is eliminating methods. Firstly, everymethod call is inlined, and then its definition is removed. It was not possible to eliminatecalls to the method eval(), since it is recursive. It was then transformed into a staticmethod and moved to the Main class. The final class diagram is depicted in Figure 3.6.


Figure 3.4 Exp1 interpreter class diagram (attributes moved up and reduced constructors)

Figure 3.5 Exp1 interpreter class diagram (methods moved up)

For further details, the source code of the original and normal form Exp1 interpreter ispresented in Appendix A.


This chapter presented a comprehensive set of transformations laws for Java, covering awide set of language features, some of them not yet addressed in the literature. Moreover,an approach to cope with open systems was devised, and the laws were adapted to be

3.5 FINAL CONSIDERATIONS 47

Figure 3.6 Exp1 interpreter class diagram (normal form)

compatible with one of its forms. To gain confidence on the relative completeness of theset of laws, a normal form reduction strategy was proposed, and through an example itseffectiveness was presented.

CHAPTER 4

PARALLELIZATION

In this unbelievable universe in which we live there are no absolutes. Even

parallel lines, reaching into infinity, meet somewhere yonder.

—PEARL BUCK (A Bridge for Passing)

This chapter presents our strategy to program parallelization. We first introduce thelaws devised to transform a sequential program into a parallel one. Subsequently, thestrategy that guides the application of the laws is presented through an example.

4.1 PARALLELIZATION LAWS

Parallelization laws are responsible to transform the source code of a sequential Javaprogram into a parallel one. In fact, these laws could have been presented before, in Sec-tion 3.2, but we decided to give them a special emphasis, in a particular chapter. Theselaws rely on the notion of independent commands, once it is the major condition in-volved in their application. One restriction of our approach is that we can perform onlystatic (conservative) dependence analysis, since our transformations are performed usingonly statically available (source code) information. This can diminish the cases whereindependent commands will be detected, but will also reduce the analysis overhead.

However, the focus of our work is not dependence analysis. We require it for theconditions of the laws to hold, but we will abstract from its details and simply use thepredicate indep(cmd1, cmd2) to indicate that two commands are independent, in fact,we also use this predicate with commands and expressions, but its meaning remains thesame. To be independent, they cannot share variables, direct or indirectly (via aliasing),unless the variables are read-only. In practice, this verification can be implemented usingone of the available methods, as described in Section 2.3.1.

With the use of the indep predicate, we claim that our laws are behavior preserving.By behavior preserving we mean that they will produce the same observable results astheir sequential counterparts. If two commands are independent, the order they areexecuted is irrelevant, and therefore they can be executed in parallel. Nevertheless, workon proofs to assure the correctness of the transformations are necessary, even when usingsuch a predicate.

We start by presenting the law to change the order of commands. It is a useful stepto group related ones and facilitate their execution in different threads. Nevertheless, toapply this law, the commands must be independent.

Law 45. 〈change command order〉If cds, A B cmds1; cmds2 then

49

50 PARALLELIZATION

cds, A B cmd1; cmd2 = cmd2; cmd1

provided

(↔) indep(cmd1, cmd2)

2

Loops that have independent commands inside their body can hinder parallelization,since they yield only two possible ways of being parallelized: parallelize the entire loop, orparallelize each iteration. Breaking them into two loops, each one containing only relatedcommands further expands the possibilities of executing them in multiple threads.

Law 46. 〈factorize loop〉

for(init; cond; incr) {cmds1;cmds2

}

=

for(init; cond; incr) {cmds1

}for(init; cond; incr) {cmds2

}

provided

(→) (1) indep(cmd1, cmd2); (2) indep(cmd1, cond); (3) indep(cmd2, cond)

2

The conditions in the previous law are usually fulfilled in loops that contain a fixednumber of iterations, which is unaffected by the commands it executes.

One further possibility in this case is to perform a data refinement in the loop condi-tion. In some cases, the condition can be the conjunction of two other conditions, eachone being affected only by a partition of the commands. In this situation we could fac-torize the loop, each new loop containing the related commands and conditions, but weleft it as a topic for future research.

One of the most common cases of parallelization is when a loop presents independentiterations. Each iteration performs some computation that does not affect subsequentloop executions. To capture this condition in the law, we parameterized cmds with theindex that controls the iteration being performed, and formulated their independenceas a predicate involving indep(cmdsi, cmdsj), whereas cmdsi and cmdsj represents theexecution of cmds in the ith and jth iteration respectively. In cases like this, the loopitself can be split, with each new loop executing a partition of the iterations from theoriginal one.

4.1 PARALLELIZATION LAWS 51

Law 47. 〈split loop iterations〉

for(int i = K; i < F ; i = i+inc)cmdsi

=

for(int i = K; i < J ; i = i+inc)cmdsi

for(int j = J ; j < F ; j = j+inc)cmdsi

provided

(→) (1) ∀i, j | K ≤ i < F ∧ J ≤ j < F ∧ i 6= j • indep(cmdsi, cmdsj)(2) indep(cmds, J) ∧ indep(cmds, F )(3) multiple(F, inc) ∧multiple(J, inc);

The previous laws have presented ways of restructuring the code aiming at a futureparallelization. The next law specifies the transformation needed to execute commandsconcurrently. To carefully introduce a concurrent execution, the law executes the orig-inal commands cmds1 in an independent thread, but before the following command, itintroduces a call to the join method, which blocks execution until the thread finishes. Inthis way, we maintain the original sequential flow. The following law captures the mostsimple way of introducing threads in an Java application.

Law 48. 〈fork - join〉If cds, A B cmds1; cmds2 then cds, A B

cmds1;cmds2

=

Thread t;t = new Thread(new Runnable() {public void run(){cmds1}});

t.start();try {t.join(); }catch(InterruptedException e){}cmds2

provided

(→) external variables accessed within cmds1 are declared as final.

2

The method join, however, throws the checked exception InterruptedException. Wehad then to address this exception, and we decided to catch it and ignore it. It isacceptable in this case because this exception is thrown when another thread interruptsthe one we are waiting for completion. In our use of the method join, we control theexecution of the thread, and we can assure no other thread will try to interrupt it.

There is also another restriction, particular to Java, that forbids non-final variables tobe accessed in methods within inner classes. Adding the final modifier to a local variable

52 PARALLELIZATION

prevents it from being assigned more than once. In fact, this limitation affects mostlyprimitive types, because when working with reference types, we can change the values oftheir attributes, even if the referencing variable is declared as final.

Nevertheless, if we maintain the sequential execution, we cannot take advantage ofmultiple processors. Moreover, Law 48, when applied solely, worsens the program per-formance. To have a simultaneous execution, and improve performance, we can movethe method join further, to after a command that is independent to the execution of thethread. In this manner, we can better explore the parallel execution of commands. Inthe following law, cmdst refers to the commands executed by t.

Law 49. 〈move join〉If cds, A B t : Thread, cmds then cds, A B

t.start();try {t.join()}catch(InterruptedException e){}cmds

=

t.start();cmdstry {t.join()}catch(InterruptedException e){}

provided

(↔) indep(cmds, cmdst)

2

Whenever there are independent commands, we can continue moving the methodjoin. If it becomes the last command within the method main, it can be eliminated,since there is no further commands to be executed, and therefore no one must wait for tto finish.

Law 50. 〈eliminate join〉

public static void main(String[ ] args) {

cmdstry {t.join()}catch(InterruptedException e){}

}

=cds,Main

public static void main(String[ ] args) {

cmds}

2

When the call to the method join is eliminated, it means that t is independent fromall subsequent commands. In this situation, t can execute in parallel without the needof any external control.

4.2 PARALLELIZATION STRATEGY 53

4.2 PARALLELIZATION STRATEGY

Our parallelization strategy receives as input a Java source code reduced to normal form(see Section 3.3.1), and produces a parallel version of it, whenever possible1, using thepreviously presented laws.

Our strategy can be divided in two major steps. The first one aims at reorganizingthe source code, making it more amenable to the parallelization. This is performed bylaws 45, 46, and 47. Thereafter, in the second step, laws 48, 49, and 50 are used toexecute independent commands in parallel.

We present our parallelization strategy using the same example as Section 3.4, startingfrom the Exp1 interpreter in normal form (Figure 3.6). The parallelization strategy doesnot change the structure of the source code. Instead, it changes how commands withinmethod bodies are executed. The source code of the class Main, which contains Exp1methods, is depicted in Figure 4.1.

A particular point about this example is that not every method definition was elimi-nated, since there is a recursive method among them. The method eval had its declarationmaintained, but as a static method in the Main class. Originally, our strategy is intendedto work on commands within the main method, but we have noted that it can also beuseful to parallelize code inside methods. In this example, we apply the parallelizationlaws inside eval ’s body because it presents the most interesting situation to explore par-allelism: the evaluation of two sides of an expression.

As stated before, the first step is to reorganize the code, grouping related commandsand splitting loops. In this case, there are no loops, but we can reorder the commandsusing Law 45. This law is applied repeatedly until all related commands are groupedtogether. The result of applying these laws can be observed in Figure 4.2.

After reordering, we can now apply the laws to execute the commands in parallel.In the method eval, there are two blocks of independent commands, each one of themresponsible for evaluating one side of the expression. Furthermore, they are followed by acommand that uses their results. This scenario fits into the fork-join law (48), but for theconditions to hold, we have to add the final modifier to the local variables lint, rint, le,and re, which can be achieved by applying Law 43. This law can be applied seamlessly,since the variables are assigned only once. We then use Law 49 to move down the callto join until before the command that depends on the thread. The resulting code isdepicted in Figure 4.3.

Now, the evaluation of each side of the expression is carried out by an independentthread, and the sequential execution continues until the result of their computation isneeded. At this point, the method join, called on each thread, assures that the executionwill resume only after they have finished. It is important to highlight that this exampleis intended to facilitate the understanding of the strategy. In this situation, parallelizingthis code would hardly deliver some speedup, due to the light computations performedin parallel.

A key point about our strategy is the termination criteria. Some laws, for instance

1Depending on how the input program is coupled, the conditions of the laws might not be satisfiedand, therefore, our strategy might not apply.

54 PARALLELIZATION

public class Main {public static _Object eval(_Object o) {

if (!(o instanceof Value)) {_Object le = o.leftExp;_Object re = o.rightExp;_Object lint = new Integer();_Object rint = new Integer();lint.val = Main.eval(le).val;rint.val = Main.eval(re).val;_Object aux = new Integer();aux.val = lint.val + rint.val;return aux;

} else {return o;

}}public static void main(String[] args) {

_Object in;_Object n1;_Object n2;_Object s;_Object v;n1 = new Integer();n1.val = 5;n2 = new Integer();n2.val = 3;s = new Sum();s.leftExp = n1;s.rightExp = n2;in = new Interpreter();in.exp = s;v = eval(in.exp);

}}

Figure 4.1 Source code of class Main

Law 47, can be applied successively until each new loop performs only one iteration. Forour purpose of speeding up execution, parallelizing code up to this level of granularitymight not provide good results, due to the overheads associated to thread creation andexecution. One thread must perform a reasonable amount of computation to compensateits creation.

One possible heuristics for this issue is to split execution according to the number of

4.2 PARALLELIZATION STRATEGY 55

public static _Object eval(_Object o) {if (!(o instanceof Value)) {

_Object le = o.leftExp;_Object lint = new Integer();lint.val = Main.eval(le).val;_Object rint = new Integer();_Object re = o.rightExp;rint.val = Main.eval(re).val;_Object aux = new Integer();aux.val = lint.val + rint.val;return aux;

} else {return o;

}}

Figure 4.2 Source code of method eval after reordering

processors available. The more processors we have, the more we can exploit them withmultiple, independent threads. Concerning this aspect, Amdahl’s law [Amd67] states themaximum speedup that can be obtained by a parallel program, taking into considerationthe number of processors (N) and the proportion of the program that can be executedin parallel (P ). It is defined by the following formula:

speedup =1

(1− P ) +P

N

It is clear by this formula that increasing the value of N yields better speedups.Nevertheless, to make use of all available processors, the parallel program must createat least N threads. There are improvements over Amdahl’s law, as for instance [Gus88],but to our purpose, it provides the necessary insights.

Having these issues in mind, we consider two possibilities to define the number ofthreads created by our strategy. The first one is to automatically obtain the number ofprocessors in the current system, and use it as the number of threads. The second oneis a user defined number of threads, that could be specified prior to the parallelization.Another alternative to split programs to be parallelized with an appropriate level of gran-ularity would be to allow the programmer to annotate chunks of code to be consideredas a unit. This is the approach taken, for instance, in [SSB04], that partitions a pro-gram into a hardware/software implementation. We consider this issue a topic for futureresearch.

56 PARALLELIZATION


final _Object le = o.leftExp;final _Object lint = new Integer();Thread t1 = new Thread(new Runnable() {

public void run() {lint.val = Main.eval(le).val;

}});t1.start();final _Object rint = new Integer();final _Object re = o.rightExp;Thread t2 = new Thread(new Runnable() {

public void run() {rint.val = Main.eval(re).val;

}});t2.start();_Object aux = new Integer();try { t1.join(); } catch (InterruptedException e) {}try { t2.join(); } catch (InterruptedException e) {}aux.val = lint.val + rint.val;return aux;

} else {return o;

}}

Figure 4.3 Source code of method eval parallelized


This chapter presented the laws devised for parallelizing Java programs. There are lawsdefined to prepare the code for a future parallelization, as well as laws to execute selectedcommands in parallel. We have then presented our parallelization strategy, describinghow the previous laws can be used to parallelize programs in normal form. The strategywas explained with the same example used in the previous chapter, which was transformedinto a parallel program, while preserving its original behavior.

CHAPTER 5

CASE STUDIES

Don’t be too timid and squeamish about your actions. All life is an

experiment. The more experiments you make the better.

—RALPH WALDO EMERSON

This chapter presents the case studies used to evaluate our parallelization strategy.We have obtained their code from the Java Grande Benchmark suite (JGB) [SBO01],which presents three sections of benchmarks, some of them having sequential and parallelversions. Our idea is to parallelize sequential code and compare its performance to theJGB parallel implementation, giving us some insight on how our approach performs incontrast to code parallelized manually.

5.1 METHODOLOGY

To perform our case studies, we started by obtaining the original sequential code fromthe selected benchmarks, and isolating them from the remaining code, working only withthe classes involved in the particular benchmark we intend to perform. The original codeprovided three different input sizes for each benchmark, but we chose to use only thesmallest one. To our purpose of assessing parallelization speedups, only one input sizesuffices.

This code is then used as input to the normal form reduction strategy. We havemanually applied the laws, following the strategy proposed in Subsection 3.3.2, until theprogram satisfied the normal form. As already expected, applying the laws manually hasproved to be very complicated in some cases. Our major difficulty was to inline methodcalls, because we had to perform it several times inside a method body, and consequentlyrename variables for each inlined call. We have then used the Intellij IDEA [Jet] integrateddevelopment tool to perform method inlining, because it inlines methods in a compatibleway to our laws, automatically renaming variables.

The next step is to apply our parallelization strategy. At this time, the lack of toolsupport also complicated our work. Reordering commands to group the related ones,particularly when working with hundreds of commands, is not a easy task to performmanually. Therefore, we decided to apply a more focused parallelization, targeting themain loops of each benchmark, and applying the appropriate laws on them.

To check whether the transformations preserved the original behavior, we used thevalidation mechanism, based on testing, from the JGB benchmark itself. When anybenchmark is executed, it performs three main stages: build the test data, execute thetest, and validate its results. The validation compares the results to a set of referencevalues, and if they do not match, an error message is reported.

57

58 CASE STUDIES

After finishing the code transformations, we compare each one of them, with respectto their execution time. Thus, we consider four source codes to do the comparison: theoriginal sequential version (OSV), the normal form version (NFV), our proposed parallelversion (PPV), and the parallel version provided by the JGB (JGBPV). At this point,it is important to discuss a major difference between our PPV and the JGBPV. TheJGBPV is a restructured parallel version that required some relevant modifications inthe OSV, the kind of modifications that demand human intervention. On the otherhand, our version, although obtained by manual applications of laws, is straightforwardand possibly mechanizable, since the transformations are specified in a compatible levelto be automated by tool support. There are, however some difficulties in this automation,as for instance, dependence analysis. These differences are the motivation to compareboth versions.

To obtain the execution time of each benchmark, we use the timer provided by theJGB, which is started before the execution of the test, and stopped when it finishes.Moreover, to present a better picture of how each version compares to each other, wealso provide their speedups, relative to the original sequential version. To calculate theexecution time data, we execute each code ten times, calculate their average (arithmeticmean), and use this value in the comparison.

The tests were performed on a core 2 duo T7250 2.0 GHz laptop, with 1GB of RAM,running Ubuntu Linux 8.04 (kernel 2.6.24-19), and Sun’s JDK version 1.6.0 06. Wereplicated the same execution conditions on each test, to avoid external factors influencingthe results.

5.2 FOURIER SERIES

Our first test was performed with the Fourier series benchmark. This benchmark calcu-lates the first 10.000 Fourier coefficients of the function f(x) = (x + 1)x on the interval0-2. Prior to apply our proposed transformation strategy, some minor adaptations wereperformed on the original classes, such as: removing all package and import clauses, andeliminating one implements clause (without any effect to our code). There were also twoutility classes: JGFInstrumentor, and JGFTimer ; that were included as external code(only compiled code). The classes we used as the starting point are depicted in Figure 5.1.

Figure 5.1 Fourier series benchmark starting classes

5.2 FOURIER SERIES 59

Following our normalization strategy, we have introduced a new root superclass,Object. After that, we changed the class hierarchy, making SeriesTest to extend from the

new root superclass. JGFSeriesBenchSizeA was renamed to Main, since it is the entrypoint to the execution. The attributes were moved up, firstly from JGFSeriesBench toSeriesTest, and then from SeriesTest to Object.

The methods were also moved up to the superclasses, likewise the attributes. Afterbeing moved to the top superclass, every method call was inlined, and had its definitioneliminated. The resulting classes can be observed in Figure 5.2.

Figure 5.2 Fourier series benchmark in the normal form

Applying the normalization strategy to the Fourier series benchmark was ratherstraightforward. There were no constructors defined, as well as no method redefinitions.Most attributes and variables are from primitive types, as well as parameters and returntypes from methods.

After obtaining our normal form, we applied our parallelization strategy. As alreadysaid in the beginning of this chapter, we focused on the main loop of the application; theloop which carries out the computation of each courier coefficient. We detected that thisloop presented data based parallelism, since each iteration works on independent data,and each iteration of the loop does not depend on previous ones. Given this scenario, weapplied Law 47, and split the original loop into two new ones, each one executing a halfof the original iterations. Following the heuristics presented in Section 4.2, we appliedthis law only once, since our test computer has two cores. After splitting the loop, weapplied Laws 48 and 49 to execute each of its partitions in parallel.

We have then compared the execution of the resulting code with the other versions,and the results are depicted in Table 5.1 and Figures 5.3, and 5.4.

The results have shown that, in the Fourier series benchmark, our approach was ableto obtain a 78,6% speedup over the original sequential version, slightly better than theJGB’s parallel version (78,5%). This was quite a surprise, since manually written parallelcode tends to perform better. Manually written code has the advantage of structuring thesystem in a way it best fits the requirements of a parallel execution; on the other hand,the transformations we perform are more limited. Moreover, the code in the normal formhad a better performance than the original one, providing some evidence that the normal

60 CASE STUDIES

Fourier SeriesOSV NFV PPV JGBPV

execution time (s) 9.6202 9.5534 5.3866 5.3896speedup - 1.007 1.786 1.785speedup (%) - 0.7% 78.6% 78.5%

Table 5.1 Fourier series benchmark execution data

Figure 5.3 Execution time in the differentFourier implementations

Figure 5.4 Speedups in the different Fourierimplementations

form reduction strategy does not incur in execution overheads.

5.3 IDEA ENCRYPTION

The IDEA benchmark performs IDEA [Sch93] (International Data Encryption Algorithm)encryption and decryption algorithm on an array of randomly generated three millionbytes. The structure of its code is similar to the Fourier benchmark, but some imple-mentation details hindered the use of our strategy. In addition to removing packages andimplementation clauses as it was done in the previous case study, we had to perform aminor change in the algorithm, moving an external variable into a loop. Except for this,all transformations are covered by our normalization and parallelization strategies. Thestarting classes are depicted in Figure 5.5.

Following our normalization strategy, we have introduced a new root superclass,Object, and changed the class hierarchy, making IDEATest extend the new root su-

perclass. JGFCryptBenchSizeA was renamed to Main, since it is the entry point to theexecution. The attributes were then moved up, firstly from JGFCryptBenchSizeA toSeriesTest, and then from IDEATest to Object.

The methods were also moved up to the superclasses, and then, every method callwas inlined. At this point, the method inv could not be inlined, because it employed

5.3 IDEA ENCRYPTION 61

Figure 5.5 IDEA encryption benchmark starting classes

multiple return statements inside conditionals. Methods had their definitions eliminated,except inv, that was then turned into a static method and moved to the Main class. Theresulting classes can be observed in Figure 5.6.

Figure 5.6 IDEA encryption benchmark in the normal form

As in the previous case study, our parallelization strategy was focused on particularloops performed by the benchmark. In this case, there were two loops to be parallelized,one that encrypts the data, and other that decrypts it. Both loops presented data basedparallelism, and thus were split once using Law 47. After that, we applied Laws 48 and 49to execute each new partition in parallel.

We have then compared the resulting code with the other versions. The data ob-tained from the experiment is depicted in Table 5.2, and their comparison is depicted inFigures 5.7 and 5.8.

In this case, our approach provided worse speedups (54.24%) than the JGB’s parallel

62 CASE STUDIES

IDEA EncryptionOSV NFV PPV JGBPV

execution time (s) 1.3670 1.3631 0.8863 0.8016speedup - 1.0029 1.5424 1.7053speedup (%) - 0.29% 54.24% 70.53%

Table 5.2 IDEA encryption benchmark execution data

Figure 5.7 Execution time in the differentIDEA implementations

Figure 5.8 Speedups in the different IDEAimplementations

version (70.53%). This is what we have previously expected, but we believe the worsespeedup is compensated by the lesser effort required to parallelize it, when comparedto the JGB version. Concerning the normal form version, it performed similarly to theprevious case study.


We have performed two case studies using code from a real world benchmark suite forJava. These experiments were used to test if our strategy delivered the results we ex-pected, and if it was feasible to be used in a code with an average complexity. Thestrategy proved to be difficult to be carried out manually, and for some specific transfor-mations, we used tool support. Nevertheless, the code fulfilled most of our restrictions,whereas only in one case we had to perform non trivial changes on it.

It is also clear that our case studies comprised a well defined class of problems inparallel computing, which present data based parallelism. The data obtained from theexperiments delivered good results, providing indications that our strategy, in this classof problems, delivers speedups competitive with manually parallelized code.

CHAPTER 6

CONCLUDING REMARKS

In the depths of winter I finally learned there was in me an invincible

summer.

—ALBERT CAMUS

In this work we have presented how a subset (representative in practice) of sequential Javaprograms can be transformed into a parallel one by means of algebraic laws. The purposeof using algebraic laws to obtain the parallelization is two fold: (1) the transformation ispotentially mechanizable (2) we provide a framework to future proofs that the resultingparallel program has the same observable semantics of the original (sequential) version.However, to achieve these top-most goals, a long track was covered.

We have developed a comprehensive set of transformation laws for Java, which werebased on previous laws defined for a formal object-oriented language with copy (as op-posed to reference) semantics. Some new laws were proposed, as well as substantialmodifications were needed for existing laws. We have also defined a reasonable set oftransformation laws aimed at constructors, which, to our knowledge, were not yet ex-plored in this depth. We have also devised an approach to address a limited form of opensystems. An issue that, to our knowledge, has not been addressed before as well.

Our work has also shown that using transformation laws in commercial programminglanguages was harder than we expected. In [SB06], they claim ROOL is based in a subsetof Java, but nevertheless, using its laws in Java is not always straightforward. We believethere is a major difference when working with real world languages. The designers ofJava had much more issues in mind when conceiving the language, and at some points,the similarity of the language with previous ones was favored over its uniformity, this canbe observed by the use of return clauses, an evident heritage from C/C++. This lack ofuniformity hinders reasoning with the language, leading to more complicated laws thanit was previously expected.

The relative completeness of the laws in this work was established by a normal formreduction strategy. The strategy has been illustrated through a case study. The lawswere also thoroughly revised, using the official Java specification [GJSB05] as a reference.We do believe the proposed laws can be a good reference for implementing programtransformations in Java.

Besides being used to claim the relative completeness of our laws, the definition ofa normal form reduction is used as the starting point of a parallelization strategy. Inthis form, most method calls are inlined, turning the main method into a big sequence ofcommands. This coding structure facilitates the work with fine grained parallelization ata command level. We also believe that working with code in a controlled format facilitatesautomation and dependence analysis, although we have not experienced with it yet.

63

64 CONCLUDING REMARKS

Finally, we performed two case studies using well established code from the JavaGrande Benchmark suite; a reference for benchmarking Java virtual machines. Theyhave shown us that the parallel computing class of problems can be very likely to deliverinteresting speedups when our approach is used. The resulting speedups were comparedto the manually implemented parallel version provided by the suite, and in one case thespeedups were almost the same and in the other it performed worse, but still obtainingsignificant speedups over the original version. Moreover, our parallel version followed atransformation strategy based on algebraic laws, a more reliable approach than restruc-turing code manually as they have done.

6.1 RELATED WORK

Concerning algebraic laws for Java, there is some related work, which is more focused onproving refactorings. For instance, the work [GM06] uses Maude [CDE+02] to formalizeJava and prove some transformations. The only work we have found about refactoringsfor Java constructors is [NCLM03], but they focus on refactoring constructors to creatormethods, instead of exploring algebraic properties of constructors as we do here.

There is some work on parallelizing Java programs, such as [BVG97, AGMM00, Che03,Fel03, CA04, BA07]. The javar restructuring compiler [BVG97] implements source tosource transformations intended to parallelize java code. In order to detect which partsof the code will be parallelized, it relies on user annotations. In [AGMM00], they focus onautomatic parallelization of loops, obtaining significant speedups over the original code.The parallelization is automatically performed in compilation time, by a specific compilerdeveloped by them.

Java programs are parallelized in the bytecode level in [Che03]. This approach hasvery good results, as well as it can be applied even when there is no source code available.Its major drawback, however, is that it uses a processor specific optimization, restrictingtheir practical use. The approaches presented in [Fel03, CA04] parallelize method calls,using annotations in the code and run-time engines. They present interesting results, butthe granularity of parallelization is restricted to method calls, as well as they require theuse of an extra framework and/or a runtime engine to work properly. A new technique,based on traces, is used in [BA07] to analyze a Java program, detect dependencies, andparallelize it. Their approach is automatic, and relies on a modified virtual machine toperform the analyses and transformations devised by them.

Formal languages, such as Circus [CSW03], provide a better reasoning mechanism towork with transformations. Therefore, there are transformations defined to split Circusprocesses [ACW03]. This approach has two major drawbacks to be reused in Java: itis applied in a formal language with copy semantics and there is no memory sharingbetween processes in Circus, as they adopt a message based approach to communicationbetween processes.

The work presented in [SSB04] served as inspiration to our approach. There, a pro-gram written in occam [Bur87] is split in many different processes and therefore groupedto decide which ones are going to be implemented in hardware or in software. Whendependent commands are split in different processes, they introduce communication be-

6.2 FUTURE WORK 65

tween them to maintain the original semantics. The parallelization in this case has thespecific purpose of facilitating the hardware software co-design, a different focus than wehave.

6.2 FUTURE WORK

We divided our future work into the following major categories:

New Java laws - we can work on eliminating some restrictions to our approach, accept-ing features not addressed by the laws. It would require also the definition of lawsfor these features, as well as the adaptation of the normal form reduction strategy.There are some important Java features that we find interesting to be taken intoconsideration, for instance, exceptions, interfaces, and generics. It would be alsointeresting to address general open systems, allowing us to use our approach in awider range of systems.

Correctness - we are aware that our laws require more work to be safely used, aswe know that defining algebraic laws for a real-world programming language isa very delicate task. In this direction, we have two major future works: toolsupport and formal proofs. By providing tool support to automatically perform thetransformations we have specified, we could validate the laws pragmatically, testingif using them is feasible in practice. One of the motivations of using algebraic lawsin our approach was exactly facilitating further work on proving them, it then arisesas an immediate future work. One major challenge, however, is to find a suitableformal semantics for Java that encompasses all the features used here. MiddleweightJava [BPP03] poses as an interesting semantics, but it does not address everthingwe need. The formalization of Java in Maude used by Garrido et al in [GM06] canalso be interesting, as it has the advantage of Maude’s tool support [CDE+03].

Parallelization laws and rules - our parallelization laws are very simple, thus, to ob-tain speedups with them, we must apply at least two laws subsequently. We couldthen define parallelization rules, which are well known compositions of laws. Anexample is the parallelization of loops. In this case, a rule can be defined to splitthe loop, execute each new partition in parallel, and move the join call to afterthe last loop. Moreover, more parallelization laws can be defined to address morelanguage constructs, as for instance, while loops.

Experiments - developing more case studies, involving more classes of systems than wehave experimented with, is an importante future work. In this way we could testwhat classes of system are more amenable to be parallelized by our strategy, as wellas which features can hinder its use. Moreover, the case studies could use morestatistical analysis. We have used some statistics to hint at the performance gainsof our approach, but to assure them, we must perform longer experiments, with alarger number of repetitions, and with random executions.

66 CONCLUDING REMARKS

Focused parallelization - it is well known to the performance tuning community thatusually a small part of the code is responsible for most of the execution time. Wecould take advantage of this property and devise a focused parallelization strategyapplied to the critical performance parts of the code. This strategy could also helpcoping with general open systems, since it would be easier to maintain the interfaceof the system unchanged.

Heuristics and scaling - another point that requires more study is the heuristics usedto define the level of parallelization. We have used a very direct heuristics that pre-sented good results, but we believe it can be refined to deliver even better speedups.To evaluate it, it would be also important to execute the parallelized code in com-puters with more processors, this way we could verify if our approach scales withthe number of available processors.

BIBLIOGRAPHY

[ACH+07] Eric Allen, David Chase, Joe Hallett, Victor Luchangco, Jan-WillemMaessen, Sukyoung Ryu, Guy L. Steele Jr., and Sam Tobin-Hochstadt. TheFortress Language Specification. Technical report, Sun Microsystems, Inc.,2007.

[ACW03] Augusto Sampaio Ana Cavalcanti and Jim Woodcock. A refinement strategyfor circus. Formal Aspects of Computing, 15, 2003.

[AF99] Jim Alves-Foss, editor. Formal syntax and semantics of Java, volume 1523of Lecture Notes in Computer Science. Springer-Verlag Inc., New York, NY,USA, 1999.

[AGMM00] Pedro V. Artigas, Manish Gupta, Samuel P. Midkiff, and Jose E. Moreira.Automatic loop transformations and parallelization for java. pages 1–10,2000.

[Amd67] G.M Amdahl. Validity of the single-processor approach to achieving largescale computing capabilities. In Proceedings of AFIPS Conference, pages483–485, 1967.

[And00] G. Andrews. Foundations of Multithreaded, Parallel and Distributed Pro-gramming. Addison-Wesley Longman Publishing Co., Inc., Boston, MA,USA, 2000.

[BA07] Borys J. Bradel and Tarek S. Abdelrahman. Automatic trace-based paral-lelization of java programs. In ICPP ’07: Proceedings of the 2007 Interna-tional Conference on Parallel Processing, page 26, Washington, DC, USA,2007. IEEE Computer Society.

[Ban88] Utpal K. Banerjee. Dependence Analysis for Supercomputing. Kluwer Aca-demic Publishers, Norwell, MA, USA, 1988.

[BENP93] U. Banerjee, R. Eigenmann, A. Nicolau, and D.A. Padua. Automatic pro-gram parallelization. Proceedings of the IEEE, 81(2):211–243, Feb 1993.

[BPP03] Gavin Bierman, Matthew Parkinson, and Andrew Pitts. MJ: An imper-ative core calculus for Java and Java with effects. Technical Report 563,Cambridge University Computer Laboratory, April 2003.

67

68 BIBLIOGRAPHY

[BS00] P. Borba and A. Sampaio. Basic Laws of ROOL: an Object-Oriented Lan-guage. In Revista de INFORMATICA TEORICA e APLICADA, Institutode Informatica-UFRGS, 2000.

[BSCC04] Paulo Borba, Augusto Sampaio, Ana Cavalcanti, and Marcio Cornelio. Al-gebraic reasoning for object-oriented programming. Sci. Comput. Program.,52(1-3):53–100, 2004.

[Bur87] A. Burns. Programming in Occam 2. Addison-Wesley Longman PublishingCo., Inc., Boston, MA, USA, 1987.

[BVG97] Aart J. C. Bik, Juan E. Villacis, and Dennis B. Gannon. javar: A proto-type Java restructuring compiler. Concurrency: Practice and Experience,9(11):1181–1191, 1997.

[CA04] Bryan Chan and Tarek S. Abdelrahman. Run-time support for the auto-matic parallelization of java programs. J. Supercomput., 28(1):91–117, 2004.

[CDE+02] M. Clavel, F. Duran, S. Eker, P. Lincoln, N. Martı-Oliet, J. Meseguer, andJ. F. Quesada. Maude: specification and programming in rewriting logic.Theor. Comput. Sci., 285(2):187–243, 2002.

[CDE+03] Manuel Clavel, Francisco Duran, Steven Eker, Patrick Lincoln, NarcisoMartı-Oliet, Jose Meseguer, and Carolyn Talcott. The maude 2.0 system. InRobert Nieuwenhuis, editor, Rewriting Techniques and Applications (RTA2003), number 2706 in Lecture Notes in Computer Science, pages 76–87.Springer-Verlag, June 2003.

[Che03] K. Chen, M.K.; Olukotun. The jrpm system for dynamically parallelizingjava programs. In Computer Architecture, 2003. Proceedings. 30th AnnualInternational Symposium on, Vol., Iss., 9-11 June 2003, pages Pages: 434–445, 2003.

[Cor04] M. Cornelio. Refactorings as Formal Refinements. PhD thesis, UniversidadeFederal de Pernambuco, 2004.

[CSW03] A. Cavalcanti, A. Sampaio, and J. Woodcock. A Unified Language of Classesand Processes. In St Eve: State-Oriented vs. Event-Oriented Thinking in Re-quirements Analysis, Formal Specification and Software Engineering, Satel-lite Workshop at FM’03, 2003.

[Fel03] Pascal Felber. Semi-automatic parallelization of java applications. In RobertMeersman, Zahir Tari, and Douglas C. Schmidt, editors, CoopIS/DOA/OD-BASE, volume 2888 of Lecture Notes in Computer Science, pages 1369–1383.Springer, 2003.

[Fow99] M. Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.

BIBLIOGRAPHY 69

[GJSB05] J. Gosling, B. Joy, G. Steele, and G. Bracha. The Java Language Specifica-tion third Edition. Addison-Wesley, 2005.

[GM96] J. Gosling and H. McGilton. The java language environment: A white paper,1996. http://java.sun.com/doc/language_environment.

[GM05] Rohit Gheyi and Tiago Massoni. Formal refactorings for object models. InOOPSLA ’05: Companion to the 20th annual ACM SIGPLAN conference onObject-oriented programming, systems, languages, and applications, pages208–209, New York, NY, USA, 2005. ACM.

[GM06] Alejandra Garrido and Jose Meseguer. Formal specification and verificationof java refactorings. SCAM, pages 165–174, 2006.

[GPB+06] Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes,and Doug Lea. Java Concurrency in Practice. Addison-Wesley Professional,May 2006.

[Gus88] John L. Gustafson. Reevaluating Amdahl’s Law. Commun. ACM,31(5):532–533, 1988.

[HHJ+87] C. A. R. Hoare, I. J. Hayes, He Jifeng, C. C. Morgan, A. W. Roscoe, J. W.Sanders, I. H. Sorensen, J. M. Spivey, and B. A. Sufrin. Laws of program-ming. Commun. ACM, 30(8):672–686, August 1987.

[Jet] Jetbrains. Intellij IDEA. http://www.jetbrains.com/idea/.

[KLZS94] Charles H. Koelbel, David B. Loveman, Mary E Zosel, and Robert S.Schreiber. The High Performance Fortran Handbook. MIT Press, 1994.

[KP05] Konstantinos Kyriakopoulos and Kleanthis Psarris. Efficient techniques foradvanced data dependence analysis. pages 143–156, 2005.

[KWB03] Anneke G. Kleppe, Jos Warmer, and Wim Bast. Mda explained: The modeldriven architecture: Practice and promise. 2003.

[Lea99] D. Lea. Concurrent Programming in Java: Design Principles and Patterns.Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1999.

[Mas07] Tiago Massoni. A Model-Driven Approach to Formal Model Refactoring.PhD thesis, Universidade Federal de Pernambuco, 2007.

[mHRU+07] Wen mei Hwu, Shane Ryoo, Sain-Zee Ueng, John H. Kelm, Isaac Gelado,Sam S. Stone, Robert E. Kidd, Sara S. Baghsorkhi, Aqeel A. Mahesri,Stephanie C. Tsao, Nacho Navarro, Steve S. Lumetta, Matthew I. Frank,and Sanjay J. Patel. Implicitly parallel programming models for thousand-core microprocessors. In DAC ’07: Proceedings of the 44th annual conferenceon Design automation, pages 754–759, New York, NY, USA, 2007. ACM.

http://java.sun.com/doc/language_environment

http://www.jetbrains.com/idea/

70 BIBLIOGRAPHY

[MMG00] Jose E. Moreira, Samuel P. Midkiff, and Manish Gupta. From flop tomegaflops: Java for technical computing. ACM Trans. Program. Lang. Syst.,22(2):265–295, 2000.

[MMG+01] Jose E. Moreira, Samuel P. Midkiff, Manish Gupta, Pedro V. Artigas, PengWu, and George Almasi. The ninja project. Commun. ACM, 44(10):102–109, 2001.

[MR90] Michael Metcalf and John Reid. Fortran 90 explained. Oxford UniversityPress, Inc., New York, NY, USA, 1990.

[NCLM03] R. Najjar, S. Counsell, G. Loizou, and K. Mannock. The role of construc-tors in the context of refactoring object-oriented systems. In CSMR ’03:Proceedings of the Seventh European Conference on Software Maintenanceand Reengineering, page 111, Washington, DC, USA, 2003. IEEE ComputerSociety.

[OMG04] OMG. MDA, Model Driven Architecture, 2004. http://www.omg.org/

mda/.

[PK03] Kleanthis Psarris and Konstantinos Kyriakopoulos. The impact of datadependence analysis on compilation and program parallelization. pages 205–214, 2003.

[PKK93] K. Psarris, X. Kong, and D. Klappholz. The direction vector i test. IEEETransactions on Parallel and Distributed Systems, 04(11):1280–1290, 1993.

[Pug91] William Pugh. The omega test: a fast and practical integer programmingalgorithm for dependence analysis. pages 4–13, 1991.

[QJ94] X. Qiwen and H. Jifeng. Laws of parallel programming with shared variables.In D. Till, editor, 6th Refinement Workshop. Springer-Verlag, 1994.

[Rat05] Justin Rattner. Multi-core to the masses. In PACT ’05: Proceedings of the14th International Conference on Parallel Architectures and CompilationTechniques, page 3, Washington, DC, USA, 2005. IEEE Computer Society.

[RH88] A. W. Roscoe and C. A. R. Hoare. The laws of occam programming. Theor.Comput. Sci., 60(2):177–229, 1988.

[RRH03] Silvius Rus, Lawrence Rauchwerger, and Jay Hoeflinger. Hybrid analysis:Static & dynamic memory reference analysis. International Journal of Par-allel Programming, 31(4):251–283, 2003.

[RSM06] Rodrigo Ramos, Augusto Sampaio, and Alexandre Mota. Transformationlaws for uml-rt. Formal Methods for Open Object-Based Distributed Systems,pages 123–137, 2006.

http://www.omg.org/mda/

http://www.omg.org/mda/

BIBLIOGRAPHY 71

[Sam97] Augusto Sampaio. An Algebraic Approach to Compiler Design. World Sci-entific, 1997.

[SB06] Augusto Sampaio and Paulo Borba. Transformation laws for sequentialobject-oriented programming. In Lecture Notes in Computer Science : Re-finement Techniques in Software Engineering, pages 18–63, 2006.

[SBO01] L. A. Smith, J. M. Bull, and J. Obdrzalek. A parallel java grande bench-mark suite. In Supercomputing ’01: Proceedings of the 2001 ACM/IEEEconference on Supercomputing (CDROM), pages 8–8, New York, NY, USA,2001. ACM.

[Sch93] B. Schneier. The idea encryption algorithm. Dr. Dobb’s Journal, pages50–56, 1993.

[SSB04] Leila Silva, Augusto Sampaio, and Edna Barros. A constructive approachto hardware/software partitioning. Form. Methods Syst. Des., 24(1):45–90,2004.

[SSH99] Silvija Seres, J. Michael Spivey, and C. A. R. Hoare. Algebra of logic pro-gramming. In International Conference on Logic Programming, pages 184–199, 1999.

[Ste05] Guy Steele. Parallel programming and parallel abstractions in fortress. page157, 2005.

[Sun99] Sun Microsystems. Why are thread.stop, thread.suspend, thread.resumeand runtime.runfinalizersonexit deprecated?, 1999. http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html.

[Tan06] Peiyi Tang. Complete inlining of recursive calls: beyond tail-recursion elim-ination. In ACM-SE 44: Proceedings of the 44th annual Southeast regionalconference, pages 579–584, New York, NY, USA, 2006. ACM.

[Tio08] Tiobe Software. Tiobe programming community index for june 2008,2008. http://www.tiobe.com/index.php/content/paperinfo/tpci/

index.html.

[Wel04] A. J. Wellings. Concurrent and Real-Time Programming in Java. Wiley,2004.

[Win93] Glynn Winskel. The formal semantics of programming languages: an intro-duction. MIT Press, Cambridge, MA, USA, 1993.

[Wol95] Michael Joseph Wolfe. High Performance Compilers for Parallel Computing.Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

APPENDIX A

EXP1 INTERPRETER SOURCE CODE

This section presents the source code of the case study presented in Section 3.4. Theoriginal source code is presented in Section A.1, and the transformed code in the normalform is presented in Section A.2.

A.1 ORIGINAL CLASSES

public abstract class BinaryExpression extends Expression {

private Expression leftExp;private Expression rightExp;

public BinaryExpression(Expression leftExp, Expression rightExp) {super();this.leftExp = leftExp;this.rightExp = rightExp;

}

public void set(Expression le, Expression re) {this.leftExp = le;this.rightExp = re;

}

public Expression getLeftExp() {return leftExp;

}

public Expression getRightExp() {return rightExp;

}

}

public abstract class Expression {

public abstract Value eval();

73

74 EXP1 INTERPRETER SOURCE CODE

}

public class Integer extends Value {

private int val;

public Integer() {super();

}

public Integer(int val) {super();this.val = val;

}

public int getVal() {return val;

}

public void setVal(int val) {this.val = val;

}

public Value eval() {return this;

}

}

public class Interpreter {

private Expression exp;

public Interpreter(Expression exp) {super();this.exp = exp;

}

public Expression getExp() {return exp;

}

A.1 ORIGINAL CLASSES 75

public void setExp(Expression exp) {this.exp = exp;

}

public Value run() {return this.exp.eval();

}

}

public class Main {

public static void main(String[] args) {Interpreter in;Integer n1,n2;Sum s;Value v;

n1 = new Integer(5);n2 = new Integer(3);

s = new Sum(n1,n2);

in = new Interpreter(s);

v = in.run();}

}

public class Sum extends BinaryExpression {

public Sum(Expression leftExp, Expression rightExp) {super(leftExp, rightExp);

}

public Value eval() {Expression le = this.getLeftExp();Expression re = this.getRightExp();Integer lint = new Integer();Integer rint = new Integer();

76 EXP1 INTERPRETER SOURCE CODE

lint.setVal(((Integer)le.eval()).getVal());rint.setVal(((Integer)re.eval()).getVal());

return new Integer(lint.getVal() + rint.getVal());}

}

public abstract class Value extends Expression {

}A.2 NORMALIZED CLASSES

public class _Object {

public _Object leftExp;public _Object rightExp;public int val;public _Object exp;

}

public abstract class BinaryExpression extends Expression {}

public abstract class Expression extends _Object {}

public class Integer extends Value {}

public class Interpreter extends _Object {}

public class Main {


_Object le = o.leftExp;_Object re = o.rightExp;_Object lint = new Integer();_Object rint = new Integer();lint.val = Main.eval(le).val;rint.val = Main.eval(re).val;_Object aux = new Integer();aux.val = lint.val + rint.val;return aux;

} else {

A.2 NORMALIZED CLASSES 77

return o;}

}

public static void main(String[] args) {_Object in;_Object n1, n2;_Object s;_Object v;

n1 = new Integer();n1.val = 5;

n2 = new Integer();n2.val = 3;

s = new Sum();s.leftExp = n1;s.rightExp = n2;

in = new Interpreter();in.exp = s;

v = eval(in.exp);}

}

public class Sum extends BinaryExpression {}

public abstract class Value extends Expression {}

This volume has been typeset in LATEXwith the UFPEThesis class (www.cin.ufpe.br/∼paguso/ufpethesis).

www.cin.ufpe.br/~paguso/ufpethesis

www.cin.ufpe.br/~paguso/ufpethesis

PARALLELIZING JAVA PROGRAMS USING … · 2016-07-12 · grama Java em uma forma normal que utiliza...

Documents

Transcript of PARALLELIZING JAVA PROGRAMS USING … · 2016-07-12 · grama Java em uma forma normal que utiliza...