Determining the concrete type of expressions enables us to perform critical optimizations such as static binding and inlining. We are currently using a basic intraprocedural dataflow algorithm to statically determine the concrete type of expressions. One of the major weaknesses of this algorithm is that the result type of a send expression can not be determined unless the send can be statically bound and inlined. This hurts us in several ways. Firstly, there is a huge incentive to inline. This often forces us into over inlining which is expensive both in terms of compiled code space and compile time. Secondly, if we are unable to statically bind the send, we can not do anything. There are many cases in which the invoked method can not be uniquely determined, however the set of possibly invoked methods may return values of similar types. One obvious example of this is the print_string method.
The goal of this research is to explore algorithms for interprocedural concrete type analysis. One of the major difficulties in interprocedural concrete type analysis for object oriented languages is the mutual dependence between the call graph and concrete type information. This memo presents a simple, work-list based algorithm that simultaneously performs interprocedural concrete type analysis and constructs the call graph. Its also briefly discusses some of the issues not fully addressed by the algorithm, proposes a schedule for performing the research and discusses the related work.
A pure object model provides the power of object-oriented programming for all data and all parts of the program. It allows easy development, modification, maintenance and reusability of software. This programming style has runtime performance disadvantages though, due to the creation of intermediate objects. The expense of intermediate objects comes from the space allocation and memory references to these objects. A standard optimizing compiler takes a conservative approach in optimizing intermediate objects. Often, unnecessary intermediate objects remain in the code after optimizations are performed.
In this thesis, a framework to optimize intermediate object structures is developed. The framework replaces unnecessary loads and stores with reads and writes to variables, and it deletes unused object creations. The framework is implemented on top of the Cecil language [Chambers 93] and the Vortex compiler. Cecil is a purely object-oriented language and Vortex is an optimizing compiler for the Cecil language written entirely in Cecil. The Vortex compiler provides a general framework to do dataflow analysis which allows optimizations to be added easily.
This paper is organized as follows. The next section provides an example to motivate why intermediate objects are expensive and how they can be optimized. In section 3 we describe the details of the optimizing framework. In section 4 we evaluate the performance of our framework and discuss the results of the study. Section 5 talks about related work and section 6 about future research directions.
Recently, Java has gain much attentions. It is a simple, robust, object-oriented, general-purpose programming language. Currently, Java is designed as a platform-independent language. A Java program is compiled into binary files called class files. Those files contain instructions of the Java Virtual Machine called bytecodes. To execute a Java program, one has to have a Java interpreter on the computer and invoke the interpreter. The interpreter will emulate the Java Virtual Machine which in turn executes the bytecodes in the class files.
Because of its platform-independency, normally interpreter is needed to run every Java program. Interpreter execution is known to be slow. One method of increasing performance is to generate, instead of machine-independent class files, real native platform-specific binaries. This will eliminate the need of the interpreter and the computer can execute the program directly.
In this thesis, I developed a program called Javelin. This program translates the Java Virtual Machine bytecode into the Vortetx Compiler s register transfer language (RTL). The RTL program is then compiled with the Vortex compiler to generate native machine code. Much of the implementation of Javelin is based on Javap, an existing Java disassembler from Sun Microsystems Inc. distributed with the Java Developer s Kit (JDK), version 1.0.