A generational on-the-fly garbage collector for Java

Citation
T. Domani et al., A generational on-the-fly garbage collector for Java, ACM SIGPL N, 35(5), 2000, pp. 274-284
Citations number
28
Categorie Soggetti
Computer Science & Engineering
Journal title
ACM SIGPLAN NOTICES
ISSN journal
15232867 → ACNP
Volume
35
Issue
5
Year of publication
2000
Pages
274 - 284
Database
ISI
SICI code
1523-2867(200005)35:5<274:AGOGCF>2.0.ZU;2-Z
Abstract
An on-the-fly garbage collector does not stop the program threads to perfor m the collection. Instead, the collector executes in a separate thread (or process) in parallel to the program. On-the-fly collectors are useful for m ulti-threaded applications running on multiprocessor servers, where it is i mportant to fully utilize all processors and provide even response time, es pecially for systems for which stopping the threads is a costly operation. In this work, we report on the incorporation of generations into an on-the- fly garbage collector. The incorporation is non-trivial since an on-the-fly collector avoids explicit synchronization with the program threads. To the best of our knowledge, such an incorporation has not been tried before. We have implemented the collector for a prototype Java Virtual Machine on AIX , and measured its performance on a 4-way multiprocessor. As for other generational collectors, an on-the-fly generational collector has the potential for reducing the overall running time and working set of an application by concentrating collection efforts on the young objects. Ho wever, in contrast to other generational collectors, on-the-fly collectors do not move the objects; thus, there is no segregation between the old and the young objects. Furthermore, on-the-fly collectors do not stop the threa ds, so there is no extra benefit for the short pauses obtained by generatio nal collection. Nevertheless, comparing our on-the-fly collector with and w ithout generations, it turns out that the generational collector performs b etter for most applications. The best reduction in overall running time for the benchmarks we measured was 25%. However, there were some benchmarks fo r which it had no effect and one for which the overall running time increas ed by 4%.