Name
Abstract | ||
|---|---|---|
Many garbage-collected systems use a single garbage collection algorithm across all applications. It has long been known that this can produce poor performance on applications for which that collector is not well suited. In some systems, such as those that execute stand-alone compiled executables, an appropriate collector for each application can be selected from a pool of available collectors and tuned by using profile information. In a study of 20 benchmarks and several collectors, compiled with the Marmot optimizing Java-to-native compiler, for every collector there was at least one benchmark that would have been at least 15% faster with a more appropriate collector. The collectors are a copying collector, a generational copying collector, which is combined with each of 4 different write barriers, and the null collector, which allocates but never collects. A detailed analysis of storage management costs shows how they vary by application and collector. |
Year | DOI | Venue |
|---|---|---|
2000 | 10.1145/362426.362472 | Sigplan Notices |
Keywords | Field | DocType |
garbage collection,col,garbage collector,memory allocation | Garbage,Computer science,Parallel computing,Copying,Compiler,Real-time computing,Memory management,Garbage collection,Storage management,Operating system,Executable | Conference |
Volume | Issue | ISSN |
36 | 1 | 0362-1340 |
ISBN | Citations | PageRank |
1-58113-263-8 | 24 | 1.69 |
References | Authors | |
13 | 2 | |
Name | Order | Citations | PageRank |
|---|---|---|---|
| Robert P. Fitzgerald | 1 | 132 | 69.13 |
| David Tarditi | 2 | 258 | 25.74 |