In this paper we seek to provide a foundation for the study of the level of use of object-oriented techniques in Java programs in general, and scientific applications in particular. Specifically, we focus on the use of small methods, and the frequency with which they are called, since this forms the basis for the study of method inlining, an important optimisation technique. We compare the Grande...

In this paper we seek to provide a foundation for the study of the level of use of objectoriented techniques in Java programs in general, and scientific applications in particular. In particular we investigate the profiles of Java programs from a number of perspectives, including the use of class library methods, the size of methods called, the mode of invoke instruction used and the polymorphicity of call sites. We also present a categorisation of the nature of small-sized methods used in Java programs. We compare the Java Grande and SPEC JVM98 benchmark suites, and note a significant difference in the nature and composition of these suites, with the programs from the Java Grande suite demonstrating a less object-oriented approach. key words: Benchmark suites, Java Virtual Machine, dynamic profiling 1.

In this thesis we provide a formal framework for separate compilation of Java-like languages. We start by formalizing the Java compilation process as it is currently implemented by compilers. Indeed, the behavior of standard compilers is hard to be understood, since compilation is propagated in a complex way to sources not explicitly mentioned by the user, and a specification is completely missing. Furthermore, with this formalization we show that Java separate compilation, despite its complexity, does not satisfy some desirable properties, such as safety and equivalence with global compilation. The former states that binaries produced by a successful compilation should not throw linkage exceptions when run; the latter states that the recompilation of a subset of the existing fragments should be equivalent to the recompilation of the whole program.

Traditional, statically composed software can be globally optimized for execution speed at compile-time. For dynamically composed component software, a different execution model has to be employed to achieve comparable performance. As components are developed and compiled separately, little is known at compile-time about the environment they will be used in later. The global information required to aggressively optimize the overall system is only available after the deployment phase. In this paper, we discuss how dynamic recompilation can be employed to provide an efficient execution model for dynamically composed software.

In this paper, we describe a novel execution environment that can dynamically switch between garbage collection systems. As such, it enables selection of the most appropriate allocator and collector for a given application and underlying resource availability. Our system is novel in that it is able to switch between a wide range of diverse collection systems. It uses program annotations to guide selection of the collection system. In addition, it can automatically identify when to switch collectors when program execution behavior warrants it, i.e., it is adaptive. Our system introduces little overhead and accurately identifies the best collector for a wide range of benchmarks and heap sizes.

This paper describes the design, implementation and performance characteristics of several compacting collectors in the Java Memorymanagement Toolkit (JMTk). Compacting collectors are an important class of collectors used in several production runtimes, including Microsoft’s Common Language Runtime and IBM’s Java Runtime Environment. The development of a strategy using compaction makes an important contribution to JMTk, and provides a platform where side-by-side comparisons between compacting collectors and other important classes of collector can be made. This work should be considered but a first step into the investigation of this class of collectors. It is anticipated that through broadening the set of operations supported by JMTk and Jikes RVM that this work will also allow new classes of collectors to be implemented and compared. Although there was found to be a high cost in performing a compacting collection, it was found to be provide reduced memory fragmentation. 1.

Java Bytecode Verification was so far mostly approached from a correctness perspective. Security vulnerabilities have been found repeatedly and were corrected shortly thereafter. However, correctness is not the only potential point of failure in the verifier idea. In this paper we construct Java code, which is correct, but requires an excessive amount of time to prove safety. In contrast to previous flaws in the bytecode verifier, the enabling property for this exploit lies in the verification algorithm itself and not in the implementation and is thus not easily fixable. We explain how this architectural weakness could be exploited for denial-of-service attacks on JVM-based services and devices.

For Elias, firstborn, who gave profound meaning to existence For Nathan, who showed that there’s no such thing as too much of something good, For I would not be complete without you. Acknowledgements At the onset of this work, the road was unclear. The general direction was known, but there was no telling where we would end up. If it was, it would not be called research. To walk this path alone is not possible, or to quote Newton ‘If I have been able to see further than others, it is because I have stood on the shoulders of giants’. I am much indebted to my promotors, professor Koen De Bosschere and professor Lieven Eeckhout, for offering me the chance to start working at the ELIS department, and to encourage me to start this research. Thank you for your councel, help, understanding that not all things tried eventually work out, and to keep motivating me to run the race until the finish. Every doctoral dissertation has need of a jury (in no particular order): Prof.