Modern garbage collectors partition the set of heap objects to achieve the best performance. For example, generational garbage collectors partition objects by age and focus their efforts on the youngest objects. Partitioning by age works well for many programs because younger objects usually have short lifetimes and thus garbage collection of young objects is often able to free up many objects. However, generational garbage collectors are typically much less effcient for longer-lived objects, and thus prior work has proposed many enhancements to generational collection. Our work explores whether the connectivity of objects can yield useful partitions or improve existing partitioning schemes. We look at both direct (e.g., object A points to object B) and transitive (e.g., object A is reachable from object B) connectivity. Our results indicate that connectivity correlates strongly with object lifetimes and deathtimes and is therefore likely to be useful in partitioning objects.

Garbage collection yields numerous software engineering benefits, but its quantitative impact on performance remains elusive. One can compare the cost of conservative garbage collection to explicit memory management in C/C++ programs by linking in an appropriate collector. This kind of direct comparison is not possible for languages designed for garbage collection (e.g., Java), because programs in these languages naturally do not contain calls to free. Thus, the actual gap between the time and space performance of explicit memory management and precise, copying garbage collection remains unknown. We introduce a novel experimental methodology that lets us quantify the performance of precise garbage collection versus explicit memory management. Our system allows us to treat unaltered Java programs as if they used explicit memory management by relying

To date, the most commonly used criterion for invoking garbage collection (GC) is based on heap usage; that is garbage collection is invoked when the heap or an area inside the heap is full. This approach can suffer from two performance shortcomings, untimely garbage collection invocations and large volumes of surviving objects. In this work, we explore a new GC triggering approach called MicroPhase that exploits two observations, (i) allocation requests occur in phases and (ii) the phase boundaries coincide with times when most objects also die, to proactively invoke garbage collection yielding high efficiency. We extended the HotSpot virtual machine from Sun Microsystems to support MicroPhase and conducted experiments using 20 benchmarks. The experimental results indicate that our technique can reduce the GC times in 19 applications. The differences in GC overhead range from an increase of 1 % to a decrease of 26 % when the heap is set to be twice the maximum live-size. As a result, MicroPhase can improve the the overall performance of 13 benchmarks. The performance differences range from a degradation of 2.5 % to an improvement of 14%.

Application servers are gaining popularity as a way for businesses to conduct day-to-day operations. Currently, the most adopted technologies for Application Servers are Java and.NET. While strong emphasis has been placed on the performance and throughput of these servers, only a few research efforts have focused on the degradation behaviors. Specifically, investigating how they perform under stress and factors that affect their throughput degradation behaviors. As a preliminary study, we conducted experiments to observe the throughput degradation behavior of Java application servers and found that the throughput degrades ungracefully. Thus, the goal of this work is three-fold: (i) identifying the primary factors that cause poor throughput degradation, (ii) investigating how these factors affect the throughput degradation, and (iii) observing how changes of algorithms and policies governing these factors affect the throughput degradation. Categories and Subject Descriptors D.3.4 [Programming Language]: Processors—Memory management (garbage collection)

While the design of garbage collection algorithms has come of age, the analysis of these algorithms is still in its infancy. Current analyses are limited to merely documenting costs of individual collector executions; conclusive results, measuring across entire programs, require a theoretical foundation from which proofs can be offered. A theoretical foundation also allows abstract examination of garbage collection, enabling new designs without worrying about implementation details. We propose a theoretical framework for analyzing garbage collection algorithms and show how our framework could compute the efficiency (time cost) of garbage collectors. The central novelty of our proposed framework is its capacity to analyze costs of garbage collection over an entire program execution. In work on garbage collection, one frequently uses heap traces, which require determining the exact point in program execution at which each heap allocated object "dies" (becomes unreachable). The framework inspired a new trace generation algorithm, Merlin, which runs more than 800 times faster than previous methods for generating accurate traces [7]. The central new result of this paper is using the framework to prove that Merlin's asymptotic running time is optimal for trace generation.

ABSTRACT Concurrent garbage collectors require write barriers to preserveconsistency, but these barriers impose significant direct and indirect costs. While there has been a lot of work on optimizing write barri-ers, we present the first study of their elision in a concurrent collector. We show conditions under which write barriers are redundant,and describe how these conditions can be applied to both incremental update or snapshot-at-the-beginning barriers. We then evaluatethe potential for write barrier elimination with a trace-based limit study, which shows that a significant percentage of write barriersare redundant. On average, 54 % of incremental barriers and 83 % of snapshot barriers are unnecessary.

We argue that garbage collection should be more closely tied to object demographics. We show that this behaviour is sufficiently distinctive to make exploitation feasible and describe a novel GC framework that exploits object lifetime analysis yet tolerates imprecision. We argue for future collectors based on combinations of approximate analyses and dynamic sampling.

Programmers are writing a rapidly growing number of programs in object-oriented languages, such as Java and C#, that require garbage collection. Garbage collection traces and simulation speed up research by enabling deeper understandings of object lifetime behavior and quick exploration and design of new garbage collection algorithms. When generating perfect traces, the brute-force method of computing object lifetimes requires a whole-heap garbage collection at every potential collection point in the program. Because this process is prohibitively expensive, researchers often use granulated traces by collecting only periodically, for example, every 32 KB of allocation. We extend the state of the art for simulating garbage collection algorithms in two ways. First, we develop a systematic methodology for simulation studies of copying garbage collection and present results showing the effects of trace granularity on these simulations. We show that trace granularity often distorts simulated garbage collection results compared with perfect traces. Second, we present and measure the performance of a new algorithm called Merlin for computing object lifetimes.

Garbage collection can be a performance bottleneck in large distributed, multi-threaded applications. Applications may produce millions of objects during their lifetimes and may invoke hundreds or thousands of threads. When using a single shared heap, each time a garbage collection phase occurs all threads must be stopped, essentially halting all other processing. Attempts to fix this bottleneck include creating a single heap per thread, however this may not scale to large thread intensive applications. In this paper we explore the potential of clustering threads into related sub-heaps. We hypothesize that this will lead to a smaller shared heap, while maintaining good garbage collection parallelism. We leverage results from software module clustering to achieve this goal. Our results show that we can significantly reduce the number of sub-heaps created and reduce the number of objects in the shared heap in a representative application. This suggests that clustering may be a promising optimization technique for garbage collection in large multi-threaded systems with many shared objects. Categories and Subject Descriptors D.2.8 [Software Engineering]: Metrics—performance measures;

Pretenuring can reduce copying costs in garbage collectors by allocating long-lived objects into regions that the garbage collector will rarely, if ever, collect. We extend previous work on pretenuring as follows: (1) We produce pretenuring advice that is neutral with respect to the garbage collector algorithm and configuration. We thus can and do combine advice from different applications. We find for our benchmarks that predictions using object lifetimes at each allocation site in Java programs are accurate, which simplifies the pretenuring implementation. (2) We gather and apply advice to both applications and Jikes RVM, a compiler and runtime system for Java written in Java. Our results demonstrate that building combined advice into Jikes RVM from different application executions improves performance, regardless of the application Jikes RVM is compiling and executing. This build-time advice thus gives user applications some benefits of pretenuring, without any application profiling. No previous work uses profile feedback to pretenure in the runtime system. (3) We find that application-only advice also consistently improves performance, but that the combination of build-time and application-specific advice is almost always noticeably better. (4) Our same advice improves the performance of generational, Older First, and Beltway collectors, illustrating that it is collector neutral. (5) We include an immortal allocation space in addition