Computer Science

IBM has been supportive of Java from its beginnings in 1995, releasing its first Java virtual machine in 1996 as one of the first Java execution platforms in the industry. Since then, IBM Research has been deeply involved in developing many advanced techniques for Just-In-Time (JIT) compilation, garbage collection and other key components in the virtual machine for high performance. In 2000, the technologies evolved into the IBM Sovereign virtual machine, which has achieved and maintained industry-leading performance, and is currently used in many middleware products for all IBM platforms.

From December 1997, the Jalapeño project at IBM Research developed virtual machine infrastructure to enable innovation within the area of efficient implementation of Java applications. The system was released as the Jikes RVM open source project in October 2001. Many researchers have used the system for a wide variety of research, including garbage collection, distributed systems, compiler optimizations, and aspect-oriented programming, resulting in over 100 publications that use Jikes RVM as their underlying infrastructure and over a dozen courses have been taught using the system. The open source project has a steering committee and core team of maintainers, 50 percent of whom are from outside of IBM. Using these two execution platforms, Sovereign JVM and Jikes RVM, researchers have developed many innovative technologies, some of which are described below:

Java Virtual Machine

In the area of garbage collection (GC), IBM Research has made notable technological advances in several fronts. For example, Real-time GC is the process of collecting data that is no longer in use by an application while the application continues to run and keeping the interruptions by the collector (also called 'pause times') short and evenly spaced. The goal of this project is to produce a garbage collector with pause times that are below one millisecond in the worst case while providing highly uniform CPU utilization, low memory overhead and low garbage collection cost. To date, researchers have made progress towards these goals with a maximum pause time of two milliseconds. The results rely on 1) a high-performance read-barrier with only 4 percent CPU overhead, which is an order of magnitude faster than previous software read-barriers, by tightly integrating the collector with the compiler for optimization, 2) time-based scheduling, which we show to be fundamentally necessary for real-time response and different from most previous real-time collectors, and 3) arraylets, a technique for efficiently breaking up large arrays into smaller objects to limit the real-time cost of scan, update or move operations on large objects. Based on these techniques, researchers are able to provide guaranteed performance based on a small number of input parameters from the programmer.

Another example of GC advances is in the domain of server-side, multi-threaded Java applications (such as Web application server and portals) with multi-gigabyte heaps. Here, pause times over a second are intolerable, but pauses up to several hundred milliseconds are acceptable and should be achieved with minimal throughput hit. These requirements provide new challenges for 'server-oriented' GC: ensuring short pause times on a multi-gigabyte heap without sacrificing the high throughput; solving the memory fragmentation problems typical to server applications, which run for a very long time and allocate very large objects; and maintaining good scaling on multiprocessor hardware.

The Large heap GC project consists of two major parts: 1) a parallel, incremental, and mostly concurrent mark sweep collector, which typically reduces the pause time by 80 percent or more, bringing it down from seconds to a few hundreds of milliseconds, without sacrificing too much throughput, and 2) a parallel and incremental compactor, which not only demonstrates high scalability when running in parallel, but is also extremely efficient when running single-threaded on a uniprocessor. This latter technology almost achieves perfect compaction in the lower addresses of the heap. Running on a 24-way AIX machine, IBM’s parallel compactor shows a 27 times speed-up over the previously used compactor.

Resolving the problem of high overhead of lock operations has been another research focus area. Because of the built-in support for multi-threaded programming, Java applications tend to perform a significant number of lock operations. Thus, optimizing the lock operations was very important to improve Java performance. IBM Research addressed this problem and developed many sophisticated algorithms for Java locks. In 1998, researchers proposed a very fast-locking algorithm called thin lock based on the observation that the locks are rarely contended for in many Java applications. They then discovered that most of those contentions are temporary and enhanced the algorithm as tasuki lock. In these two algorithms, Java locks can be acquired with only one atomic operation in most cases. The team also made several attempts to further improve these algorithms, and succeeded in eliminating the atomic operation by exploiting the thread locality of Java locks.

The dynamic nature of the Java language provides opportunities for better optimization based on runtime profile information, and this is a significant advantage of a Java dynamic compiler over a traditional static compiler.

IBM researchers have made several technical advances in the area of adaptive and dynamic optimization by demonstrating 1) that using a principled cost/benefit analysis can improve system performance for short- and long-running applications by automatically determining which parts of an application should be optimized while it executes; 2) how to efficiently capture detailed profiling information with low overhead; 3) how to use the profiling information to improve performance by tailoring optimizations based on the current profile; 4) that handling and optimizing exception-intensive programs by profiling hot exception paths is practical; and 5) that compiling with a region, instead of method boundary, that results from eliminating uncommon execution paths has the potential to achieve better performance.