RTS Garbage Collection
Sign up for access to the world's latest research
Abstract
AI
AI
Java's built-in garbage collection significantly eases memory management for developers by reclaiming memory automatically, which accelerates development and helps prevent memory leaks. However, despite these advantages, Java garbage collection can lead to performance issues due to its complex and adaptable nature, necessitating a deeper understanding of memory management within the Java Virtual Machine (JVM). This paper explores the workings of garbage collection in Java, particularly the concept of garbage-collection roots, to enhance the understanding of memory management and improve performance outcomes in Java applications.
Related papers
ACM SIGPLAN …, 2002
Until recently, the best performing copying garbage collectors used a generational policy which repeatedly collects the very youngest objects, copies any survivors to an older space, and then infrequently collects the older space. A previous study that used garbage-collection simulation pointed to potential improvements by using an Older-First copying garbage collection algorithm. The Older-First algorithm sweeps a fixed-sized window through the heap from older to younger objects, and avoids copying the very youngest ...
ACM SIGPLAN Notices, 2001
Java uses garbage collection (GC) for the automatic reclamation of computer memory no longer required by a running application. GC implementations for Java Virtual Machines (JVM) are typically designed for single processor machines, and do not necessarily perform well for a server program with many threads running on a multiprocessor. We designed and implemented an on-the-fly GC, based on the algorithm of Doligez, Leroy and Gonthier [13, 12] (DLG), for Java in this environment. An on-the-fly collector , a collector that does not stop the program threads, allows all processors to be utilized during collection and provides uniform response times. We extended and adapted DLG for Java (e.g., adding support for weak references) and for modern multiprocessors without sequential consistency, and added performance improvements (e.g., to keep track of the objects remaining to be traced). We compared the performance of our implementation with stop-the-world mark-sweep GC. Our measurements sho...
In earlier languages the memory management is done explicitly by the programmer himself. Now with the advent of modern object oriented languages like Java and C# the programmer is relived from explicitly managing the memory. A special program thread known as garbage collector takes care of managing the memory implicitly. The process of automatically reclaiming memory from dead objects (the objects that are not referenced from program or any other live object) is known as garbage Collection (GC). There are various metrics that affect the performance of the mutator. In the current research paper we have experimentally tested the four garbage collectors on various benchmarks of SPECjvm2008 and calculated how much memory is reclaimed after each (minor and major) collection.
ACM SIGPLAN Notices, 2003
We present a memory management scheme for Java based on thread-local heaps. Assuming most objects are created and used by a single thread, it is desirable to free the memory manager from redundant synchronization for thread-local objects. Therefore, in our scheme each thread receives a partition of the heap in which it allocates its objects and in which it does local garbage collection without synchronization with other threads. We dynamically monitor to determine which objects are local and which are global. Furthermore, we suggest using profiling to identify allocation sites that almost exclusively allocate global objects, and allocate objects at these sites directly in a global area.
The Garbage Collection Handbook, 2011
1999
Modern programming languages such as Java are increasingly being used to write systems programs. By "systems programs," we mean programs that provide critical services (compilers), are long-running (Web servers), or have time-critical aspects (databases or query engines). One of the requirements of such programs is predictable behavior. Unfortunately, predictability is often compromised by the presence of garbage collection. Various researchers have examined the feasibility of replacing garbage collection with forms of stack allocation that are more predictable than GC, but the applicability of such research to systems programs has not been studied or measured. A particularly promising approach allocates objects in the nth stack frame (instead of just the topmost frame): we call this deep stack allocation. We present dynamic profiling results for several Java programs to show that deep stack allocation should benefit systems programs, and we describe the approach that we are developing to perform deep stack allocation in Java.
ACM SIGPLAN Notices, 2003
Until recently, the best performing copying garbage collectors used a generational policy which repeatedly collects the very youngest objects, copies any survivors to an older space, and then infrequently collects the older space. A previous study that used garbage-collection simulation pointed to potential improvements by using an Older-First copying garbage collection algorithm. The Older-First algorithm sweeps a fixed-sized window through the heap from older to younger objects, and avoids copying the very youngest objects which have not yet had sufficient time to die. We describe and examine here an implementation of the Older-First algorithm in the Jikes RVM for Java. This investigation shows that Older-First can perform as well as the simulation results suggested, and greatly improves total program performance when compared to using a fixed-size nursery generational collector. We further compare Older-First to a flexible-size nursery generational collector in which the nursery ...
One of the problems facing the use of Java for real-time environments with limited memory such as embedded systems is the unpredictability of running garbage collection. This introduces unexpected load on the system and causes undesirable delay for the real-time applications. In this paper, we study the realtime Java (RTJ) specification and some of the available implementations of RTJ such as PERC and Jbed. The main objective of the study is to determine the memory management tools provided for real-time applications that require frequent object creation. Based on this study, we propose an object-reuse technique to reduce memory requirements of intensive object creation in Java programs. This technique eliminates the need for using garbage collection and allows for a more deterministic task execution and efficient utilization of the available memory. A theoretical model is discussed and a number of benchmark tests are used to measure the different aspects of this technique. The benchmark results show that garbage collection can be eliminated and the execution time of the applications has improved. The results obtained motivated introducing a framework for enhancing and automating the object reuse technique.
ACM SIGPLAN Notices, 2001
We study the effectiveness of garbage collection (GC) algorithms by measuring the time difference between the actual collection time of an object and the potential earliest collection time for that object. Our ultimate goal is to use this study in order to develop static analysis techniques that can be used together with GC to allow earlier reclamation of objects. The results may also be used to pinpoint application source code that could be rewritten in a way that would allow more timely GC. Specifically, we compare the objects reachable from the root set to the ones that are actually used again. The idea is that GC could reclaim unused objects even if they are reachable from the root set. Thus, our experiments indicate a kind of upper bound on storage savings that could be achieved. We also try to characterize these objects in order to understand the potential benefits of various static analysis algorithms. The Java Virtual Machine (JVM) was instrumented to measure objects that are reachable, but not used again, and to characterize these objects. Experimental results are shown for the SPECjvm98 benchmark suite. The potential memory savings for these benchmarks range from 23% to 74%.

Loading Preview
Sorry, preview is currently unavailable. You can download the paper by clicking the button above.