In this paper, we present a technique for selective capture and replay of program executions. Given an application, the technique allows for (1) selecting a subsystem of interest, (2) capturing at runtime all the interactions between such subsystem and the rest of the application, and (3) replaying the recorded interactions on the subsystem in isolation. The technique can be used in several scenarios. For example, it can be used to generate test cases from users ’ executions, by capturing and collecting partial executions in the field. For another example, it can be used to perform expensive dynamic analyses off-line. For yet another example, it can be used to extract subsystem or unit tests from system tests. Our technique is designed to be efficient, in that we only capture information that is relevant to the considered execution. To this end, we disregard all data that, although flowing through the boundary of the subsystem of interest, do not affect the execution. In the paper, we also present a preliminary evaluation of the technique performed using SCARPE, a prototype tool that implements our approach. 1.

managed runtime environment (MRTE) that features exact generational garbage collection, fast thread synchronization, and multiple coexisting just-in-time compilers (JITs). ORP was designed for flexibility in order to support experiments in dynamic compilation, garbage collection, synchronization, and other technologies. It can be built to run either Java or Common Language Infrastructure (CLI) applications, to run under the Windows or Linux operating systems, and to run on the IA-32 or Itanium processor family (IPF) architectures.

Many modern applications exercise the operating system kernel significantly, resulting in several implications including affecting the control flow transfer in the execution environment. This paper focuses on understanding the operating system effects on control flow transfer and prediction, and designing architectural support to alleviate the bottlenecks.

this article, I describe the more finely grained, permission-based

64-bit processor architectures like the Intel ® Itanium® Processor Family are designed for large applications that need large memory addresses. When running applications that fit within a 32-bit address space, 64-bit CPUs are at a disadvantage compared to 32-bit CPUs because of the larger memory footprints for their data. This results in worse cache and TLB utilization, and consequently lower performance because of increased miss ratios. This paper considers software techniques for virtual machines that allow 32-bit pointers to be used on 64bit CPUs for managed runtime applications that do not need the full 64-bit address space. We describe our pointer compression techniques and discuss our experience implementing these for Java 1 applications. In addition, we give performance results with our techniques for both the SPEC JVM98 and SPEC JBB2000 benchmarks. We demonstrate a 12 % performance improvement on SPEC JBB2000 and a reduction in the number of garbage collections required for a given heap size. 1.

This paper presents the results of a characterization analysis performed on the Java Virtual Machine (JVM) using the SPECÔÔ JVM98 benchmarks. We have developed an instrument that runs inside the JVM that provides profiles of a variety of different workload characteristics. The data from these profiles are examined to better understand where performance bottlenecks exist in the JVM and what optimizations are possible. The frequency data presented is a first step in determining what instructions require special attention. The stack level information describes the number of registers needed to store stack elements. This knowledge can then be applied to the development of specialized hardware architectures or enhanced interpreters. 1. Introduction The Java Virtual Machine language has become a success with the popularity and increased number of users on the Internet. Java allows programs to be used across a wide range of machine platforms, providing a common language interface. The Java b...

This paper deals with class and interface name clashes in Java component systems that occur because of evolutionary changes during the lifecycle of a component application. We show that the standard facilities of the Java type system do not provide a satisfactory way to deal with the name clashes, and present a solution based on administering the names of classes and interfaces with a version identifier using a byte code manipulation tool. The solution is demonstrated on a proof of concept implementation.

To my family for their support in all these years iii Acknowledgment I am indebted to my family, which have given me strong support in all these years to pursue my own ambition. Special thanks to my advisors: Zvi M. Kedem and Vijay Karamcheti. It is from Zvi that I learned to appreciate simplicity and to look for inter-esting problems from ordinary tasks in the computer world. It is Vijay who showed me how to partition problems, write papers, give presentations, and keep extending current work for further goals and development. I have been working in a very good team. I had enormous help from Ayal Itzkovitz,

An in-depth look and understanding of control flow transfer and its predictability can guide architects to adapt control flow prediction hardware in Java processing or finely tune the performance of JVM software on general purpose machines. To our knowledge, this paper provides the first insight of branch behavior on a standard Java Virtual Machine with real workloads. Employing a complete system simulation environment, we profile branch execution characteristics and quantify the performance of a wide range of prediction schemes on both user and kernel code. The impact of different JVM styles (JIT compiler and interpreter) on branch behavior is also studied. We find that: (1) Kernel branches constitute a significant portion of total branch execution in Java processing; (2) Kernel and user code favor different prediction mechanisms; (3) Java processing exercises fairly large number of branch sites and large control flow footprint compared with the execution of benchmarks such as SPECInt95; (4) A major part of the dynamic indirect branches are multiple target (polymorphic) branches. Target addresses of indirect branches, especially those in interpreting mode are highly interleaved and cause high BTB misprediction. 1.

Over the past few years, Java has evolved into a mature platform for developing enterprise applications. A critical factor for the commercial success of these applications is end-to-end performance, e.g., in terms of response times, throughput and availability. This raises the need for the development, validation and analysis of performance models to predict performance metrics of interest. To develop and validate performance models, insight in the execution behavior of the application is essential, requiring advanced monitoring capabilities. In this paper we introduce our Java Performance Monitoring Toolkit (JPMT). JPMT represents internal execution behavior of Java applications by event traces. An event represents the occurrence of some activity, such as thread creation, method invocation, and locking contention. Events are annotated by high-resolution performance attributes, e.g., duration of locking contention and CPU time usage by method invocations. JPMT is an open toolkit, its event trace API can be used to develop custom performance analysis applications. JPMT comes with an event trace visualizer and a command-line event trace query tool for scripting. JPMT supports event filtering during and after application execution. The instrumentation required for monitoring the application is added transparently to the user during run-time. Overhead is minimized by only instrumenting for events the user is interested in. Furthermore, the instrumentation itself is carefully optimized. This paper discusses the architecture and implementation of the toolkit in detail and reports on our experience in applying the toolkit to model a CORBA implementation.