Efficient Object Sampling Via Weak References


Ole Agesen Alex Garthwaite
VMware Sun Microsystems Laboratories
3145 Porter Drive 1 Network Drive
Palo Alto, CA 94304 Burlington, MA 01803-0902
[email protected] [email protected]

ABSTRACT from the burden of explicitly reasoning about the use of memory
The performance of automatic memory management may be im- and eliminate two classes of errors:
proved if the policies used in allocating and collecting objects had  memory leaks errors where the application loses track of al-
knowledge of the lifetimes of objects. To date, approaches to the located memory without freeing it.
pretenuring of objects in older generations have relied on profile-
driven feedback gathered from trace runs. This feedback has been  dangling references where the application frees memory while
used to specialize allocation sites in a program. These approaches retaining references to it and subsequently accesses this mem-
suffer from a number of limitations. We propose an alternative that ory through these references.
through efficient sampling of objects allows for on-line adaption of
allocation sites to improve the efficiency of the memory system. In Garbage collectors work by handling all requests to allocate mem-
doing so, we make use of a facility already present in many col- ory, by ensuring that this allocated memory has an appropriately
lectors such as those found in JavaTM virtual machines: weak ref- typed format, and by guaranteeing that no memory is freed until it
erences. By judiciously tracking a subset of allocated objects with is proven that the application holds no references to that memory.
weak references, we are able to gather the necessary statistics to Garbage collection services typically allocate objects in a heap.
make better object-placement decisions. Periodically, the collector locates the set of objects in the heap still
reachable from the running program and frees the rest of the mem-
ory in the heap so that it may be used for new allocation requests.
1. INTRODUCTION Often, the collection technique involves stopping the application
With better knowledge of the behavior of objects in a running ap- while this process of finding the reachable objects is performed.
plication, we can make better decisions about how to manage those For large heaps, this may lead to long pauses during which the ap-
objects. These decisions may affect, for example, how and where plication is unable to proceed.
objects are placed. Typically, instrumenting all objects to gather Generational collectors are designed to address part of this pause-
this knowledge would slow the application too much to be practi- time problem. The observation is that recently allocated objects
cal. We present a technique for dynamic sampling of a subset of tend to die (that is, become unreachable) quickly. The approach
the allocated objects that incurs low runtime overheads. Coupled in generational collectors is to divide the heap into an ordered se-
with automatic memory management or collection, this technique quence of two or more subheaps or generations. Objects are allo-
allows us to improve the efficiency of the collector by segregating cated primarily in the first generation; as objects survive in a par-
objects, sampled and non-sampled alike, based on observed charac- ticular generation across collections, that generation will have a
teristics such as object lifetime. The sampling technique can track policy for promoting these longer-lived objects to the next genera-
many kinds of information but for purposes of this paper we con- tion. Most collection work is performed in the youngest generation
centrate on the improvement for generational garbage collectors. which is sized to cause most collection-time pauses to be of accept-
ably short duration.
1.1 Improving Generational Collectors One inefficiency of a generational heap, however, is that long-
Strongly typed languages like the JavaTM programming language lived objects may be copied many times before reaching the appro-
rely on automatic memory management, also known as garbage priate generation. Our technique improves generational collectors
collection. Memory management services free the programmer by identifying objects that will most likely survive to be tenured
The work presented in this paper was performed while this author to a particular generation and by allocating such objects directly
in that generation. By sampling a subset of the objects and study-
was at Sun Microsystems, Inc.
ing their lifetimes, we are able to better place objects to reduce the
number of times such objects are copied within a generation or pro-
moted between generations. A side-benefit is that by not allocating
long-lived objects in younger generations, we reduce the number
of collections in those generations. Finally, our approach uses con-
tinued sampling to dynamically track how the observed lifetimes
of objects change as the application executes. This allows the tech-
nique to adapt as the application changes the way in which it uses
objects.
1.2 Object Sampling and Fingerprinting  the time at which the object is allocated. Allocation time may
Central to our sampling technique is the use of weak references. be measured in many ways: real time, CPU time, number of
Simply put, a weak reference is a reference to an object with the collections since the start of the application, number of bytes
property that the garbage collector does not consider this reference allocated. If we combine information from allocation with
when determining the reachability of the referred-to object. As long information gathered at other points in the program, we can
as some other stronger reference keeps the object alive, the weak infer reasonable bounds on object lifetimes.
reference will continue to refer to the object. At some point, the col-  the allocation site in the program where the object is cre-
lector determines that the object is only reachable from weak refer- ated. This may include a summary of information from one
ences of a given strength. For each weak reference to the object, an or more frames of the calling context for the allocation op-
“imminent death” action is then performed, followed by clearance eration. Many different places in a program may allocate
of the weak reference so that the referred object can subsequently instances of the same class. Sometimes it might be use-
be reclaimed. Weak references can be available as first-class con- ful to distinguish between these. For example, it might be
structs in the language, as is the case with the JavaTM platform, or that String objects allocated at one site (say, used for file
they can be an implementation-level construct visible only to the names) tend to live much longer than String objects allo-
runtime system. Either kind of weak reference may be used with cated at another site (say, created to print floating point num-
our approach so long as the one chosen cannot cause an object to bers).
become reachable again.
The Java platform [10] mandates four kinds or strengths of weak  the type of the object. In most object-oriented languages, this
references under the package java.lang.ref: information does not need to be included in the fingerprint
since it is stored in the object itself. For other languages
 soft references meant to be used for implementing caches where runtime type information is not readily available, it
 weak references meant to implement canonicalization data may be approximated by some other metric such as object
structures size [3].

 final references used to implement finalization  in object-oriented languages, the type of the receiver to which
the method performing the allocation is applied. 1
 phantom references designed to schedule actions once an ob-
 an identifier for the thread performing the allocation. Objects
ject ceases to be reachable
of the same type allocated at the same allocation site by dif-
Weak references to objects are processed in order of strength. Weak ferent threads may serve different purposes and, hence, have
references, when processed, may be enqueued on a reference queue different lifespans.
for further processing by the application. For our purposes, it is
Weak references can be implemented relatively efficiently, and
important to note that finalization of objects may result in those
by varying the fraction of objects we sample, we can trade effi-
objects becoming strongly reachable again. Only phantom refer-
ciency and statistical accuracy against each other. Further, in envi-
ences are guaranteed not to resuscitate a dying object. This means
ronments like the Java platform where support for weak references
that phantom references or VM-specific weak references are ap-
already exists, we can efficiently gather statistics on sampled ob-
propriate choices for implementing our proposal in a Java virtual
jects as they become unreachable without having to explicitly ex-
machine.
amine the heap for dying objects after each collection.
As a motivating example, suppose we want to determine the
As can be seen, by including various pieces of information in the
average lifespan of certain objects. Specifically, we might want
fingerprints, and by controlling sampling rates, we can estimate:
to know if instances of a certain class X tend to live longer than
instances of a certain other class Y. Monitoring all allocations of  how many objects are allocated of each type (class)
classes X and Y to compute the exact lifespan statistics may be too
costly to be practical in the production use of most programs. How-  how many objects are allocated at each allocation site
ever, it is possible that knowing the lifespans of a small fraction of  how long each category (class, allocation site) of objects tend
all X and Y instances, say one in every 1000 allocated, allows us to live
to estimate lifespans for the entire population of X and Y instances
with a useful degree of accuracy. We can sample X and Y instances Furthermore, we can refine the above kind of information either on
effectively by attaching a weak reference to every 1000th X and Y a per-thread basis or through correlated class information. The uses
instance allocated. The weak reference tracks the instances, and the of such statistical information include optimizations in the memory
associated “imminent death” action will inform us when they cease system as well as offering a source of feedback to the program-
to be alive. Thus, we get access to both the birth and death events mer allowing the program to be better optimized or debugged. For
for a specifiable fraction of X and Y instances, from which we can instance, in the memory system, one might:
estimate their relative lifespans.
 allocate (or pretenure) certain categories of objects directly
More generally, this approach combines the use of weak refer-
into specific generations.
ences to track a sample of objects over their lifetimes with the idea
of “fingerprinting” such objects, i.e., associating additional infor-  promote objects to selected generations.
mation with the objects. The fingerprint summarizes interesting
aspects of the state of the system at the point when the object is  better place and move objects within generations, especially
allocated. A convenient place to store the fingerprint would be in in the context of systems based on the Train Algorithm [9].
association with the weak reference data structure.  choose which objects to allocate in thread-local versus global
Examples of the kind of information that one might include in areas of the memory system.
the fingerprint are:
1
Our colleague, Tim Harris, suggested this idea.
Using the data gathered about reclaimed and still-live objects and tion together with information about the state of the call stacks at
their lifespans, we can improve the efficiency of generational col- the time of allocation, they use two predictors, path point predic-
lectors through better object placement, reduction in the copying of tion and stack contents prediction, to place objects in the heap to
objects, and reduced collection of individual generations. maximize the efficiency with which the program uses virtual pages
of memory.
1.3 Roadmap Cheng, Harper, and Lee examine several techniques for improv-
In Section 2, we briefly review work related to our proposal. In ing the efficiency of generational garbage collection in the con-
Section 3, we offer our own design for a dynamic object-sampling text of the TIL compiler and runtime system for ML [5]. This
and fingerprinting framework applicable to a generational frame- work uses profile-driven feedback from sample runs to pretenure
work. Finally, we consider future work and conclude. long-lived objects to the older of a two-generation heap. To aid
in pretenuring decisions, their system tracked the observed object
2. RELATED WORK lifetimes for each allocation site. Tracking information on a per-
allocation site basis is much simpler than summarizing information
Garbage collection has a long history. Two excellent surveys of
about the dynamic call stack. Further, much of the benefits of the
the area are available from Paul Wilson [19] and Richard Jones [11].
latter can be gained through inlining of methods containing alloca-
The earliest reports on generational collectors can be traced to David
tion sites into calling contexts.
Moon [13], Henry Lieberman and Carl Hewitt [12] and their imple-
All of these approaches rely on off-line, full-run profiling of ap-
mentation of a collector for Lisp. They observed that segregating
plications. These approaches make the basic assumption that the
young objects and concentrating collection on those objects yields
profile data is representative of how objects allocated at particular
a more efficient memory system. Another pioneer in generational
allocation sites behave. This assumption is limiting for a number
collection is David Ungar who developed a simple, two-generation
of reasons. First, programs, especially concurrent ones, rarely run
collector where the heap is split into an allocation area or eden and
repeatedly with precisely the same behavior. Second, as programs
a tenured object space [15]. Ungar succinctly sums up the genera-
scale to large sizes (for example, ones with heaps greater than 1
tional hypothesis: “most young objects die young.” A good account
GB), the lifespans of objects and their relative proportions shift.
of the benefits of generational collectors may be found in [1].
Finally, as programs execute, they go through phases. Objects allo-
Unfortunately, there are limits to the generational hypothesis.
cated at a given allocation-site may exhibit different lifespans de-
While the observation generally holds true of recently allocated
pending on the phase in which they are allocated. Profile-driven
objects, there is no stronger statement supporting the idea that the
feedback is unable to track such shifts in behavior within a run-
older an object is the longer it is likely to live. Ungar and Jackson
ning application. Our approach using weak references to finger-
improved the efficiency of a two-generation collector for Smalltalk
print sampled objects avoids these problems with negligible over-
by explicitly segregating some kinds of objects and by using a dy-
head on the performance of the application.
namically computed threshold for deciding when to promote ob-
jects [16, 17]. Barrett and Zorn extended this idea further by col-
lapsing the two generations and using a movable “threatening bound- 3. DESIGN
ary” to separate the spaces for short- and long-lived objects [2]. Pretenuring or the automatic placement of objects at allocation
In the absence of information about the lifespans of objects, a time breaks down into the following set of tasks or choices:
number of proposals have been put forward to improve the effi-
ciency of older generations. Most recently, work by Will Clinger 1. Object selection or sampling
and Lars Hansen, and by Darko Stefanovic, Eliot Moss, and Kathryn 2. The fingerprinting mechanism
McKinley has examined the idea of “oldest-first” collectors [6, 14].
Our proposal differs in that we attempt to improve the collector by 3. The level and kind of data gathered for each object
having knowledge about the objects in the heap. In this sense, it
is orthogonal to “oldest-first” collection techniques and may even 4. The summarization of gathered data
improve these techniques by placing objects where they are likely
5. Method (re)adaptation
to be collected shortly after dying.
David Hanson developed a malloc implementation for the C In this section, we outline approaches to each of these steps.
language that allows for explicit placement of allocation requests [7]. The platform we will use to implement our approach to dynamic
Barrett and Zorn extended this work by developing a technique for adaptive tenuring is the ResearchVM.2 This platform provides a
profiling the allocation behavior of programs [3]. The two met- number of facilities including:
rics they used were allocation size (since C lacks appropriate type
information) and a summary of the state of the call stack at the  the ability to configure the number, size, and policies of gen-
time of allocation. Using the profile information generated from erations forming the heap
tracing the applications, they augmented the malloc library with
 support for both application-level and VM-specific classes of
a database consisting of allocation sites where objects always die
weak references
quickly. This technique allows them to separate long lived objects
from short lived ones, simultaneously reducing fragmentation, al-  support for method recompilation including a number of op-
lowing the short lived objects to be allocated together on pages, and timizations such as the inlining of methods
allowing these pages to be freed at once.
Seidl and Zorn have studied the notion of pretenuring objects The basic memory structure of the ResearchVM is described in
based on how the objects are referenced and what the observed [18].
lifespans of the objects are [20]. Using profile-driven feedback 2
The Sun Laboratories Virtual Machine for Research or Re-
from sample application runs, they classify objects allocated at searchVM is currently being used as the Java virtual machine in
given sites in the program into categories: short-lived, highly refer- the JavaTM 2 Standard Edition for the SolarisTM Operating Environ-
enced, not highly referenced, and other. Combining this informa- ment and was formerly known as the ExactVM.
3.1 Sampling Techniques  more of the tenuring infrastructure can be expressed in the
Since sampling is done when objects are allocated and since the Java programming language and is, thus, more portable to
tenuring decisions are made at allocation sites, it makes sense that other Java virtual machines.
any decision on how to implement object sampling affects the allo-
The disadvantage is that phantom references occupy space in the
cation code at these sites. Because allocation is a frequent activity,
heap and may affect the rate at which collections occur. This dis-
it is good to sample objects in a manner that does not impact the
advantage may be lessened in two ways: the sampled object and its
common case.
phantom weak reference object could be allocated in one operation
The key to obtaining low overhead sampling is to avoid intro-
and if the ratio of sampled objects to non-sampled objects is low
ducing overhead on the allocation of non-sampled objects. The Re-
then the impact should be minimal. The advantage of VM-level
searchVM memory system already contains several mechanisms by
weak references include:
which this can be achieved:
 the lack of constraints on the format in which the fingerprint-
 Local allocation buffers (LABs). We can chose to sample
ing information is represented. For example, we can main-
only the objects that cause a LAB refill. This is a low-pressure
tain arrays of such references and process these arrays with
point in the allocation system. Care must be taken in this
bulk operations.
case since large objects tend to overflow LABs more often
than small objects, resulting in skewed samples.  the fact that these weak references are allocated outside the
heap.
 Custom-allocator routines can be used to achieve cheap sam-
pling for specific classes. The primary disadvantage to this approach is that the resulting sys-
tem is entirely VM-specific.
 The allocator routines already take a thread identifier as an
argument. By comparing this identifier against a global vari- 3.3 Gathering Statistics
able or mask, we could obtain thread-specific sampling. To
There are several ways in which statistics on objects can be gath-
cover multiple threads, the global variable can be slowly ro-
ered:
tated among the threads. Alternatively, we can have a per-
thread flag indicating if a thread should be considered for  at the time an object is allocated and sampled
sampling.
 when a sampled object becomes unreachable and dies
The most common technique for sampling will likely use the first
approach. One might think that we could overcome the bias men-  in the event that the weak references are linked together, by
tioned for large objects by sampling the first object allocated once iterating over the list of sampled objects
the local allocation buffer is refilled. Unfortunately, this alternative
Combining the first two approaches allows us to incrementally main-
introduces a different kind of bias since allocation of large objects,
tain information about object lifespans without having to traverse
for example, character arrays, are often correlated with the alloca-
potentially long data structures. For a simple, two-generation heap,
tion of other objects, such as the String objects managing those
the statistics may take the form of a mean object lifespan and de-
arrays. On the other hand, one could argue that such a bias is appro-
viation. More generally, though, it may take the form of one or
priate for large objects since these objects incur higher costs when
more histograms to support tenuring decisions with more than one
copied by the garbage collector. In any event, customization of
generation. The data on lifespans may be used to determine when
allocator routines is handled by having a per-class allocation func-
objects allocated at a given site live long enough to justify being
tion. So, another approach to the bias issue is to support several
placed in a particular generation.
LABs per thread and to use custom-allocators to allocate different
For sampled objects that are still living, we can best gather their
sizes of objects.
birth time statistics in a histogram at the time they are allocated. As
3.2 Fingerprinting sampled objects die, we can remove their contribution to the appro-
priate bucket of the histogram, in the process maintaining an up-to-
We have already discussed the importance of weak references as
date histogram of the birth times and counts of reachable sampled
a mechanism for associating information with objects as they are al-
objects. Using this histogram together with the current time, we can
located. The ResearchVM supports the four application-level weak
calculate the distribution of lifespans for objects allocated at a given
references mandated by the Java Language Specification as well as
site in the program. For sampled objects that become unreachable,
several kinds of VM-level weak references. Examples of the lat-
we can gather their lifespan information in a second histogram di-
ter kind include the hash tables supporting the interning of strings
rectly. Combining these two distributions, we can easily determine
and the maintenance of loader constraints generated through class
where best to allocate or promote a given object.
loading, resolution, and verification. For our purposes, the appro-
priate choices of weak references are either phantom references or 3.4 Representation of Statistics
VM-level references since neither of these kinds may result in a dy-
Allocation-site information may include static information such
ing object to become reachable again when their “imminent death”
as the program counter of the allocation instruction or the method
operations are performed. Phantom references offer several advan-
containing it as well as dynamic information summarizing the top
tages:
frames of the call-stack, the identity of the thread allocating the
 the PhantomReference class is easily extended to in- objects, or the receiver-object of the method in which the alloca-
clude the data associated with the object. tion occurs. All of these may be used to refine the summary data
gathered.
 the collector need only queue the phantom references for pro- However, the two key pieces of information required for mak-
cessing instead of processing them during a collection phase. ing tenuring decisions include the object’s age and the site in the
program at which it is allocated. As mentioned above, there are a
number of different metrics that may be used to measure age and is determined, the methods dependent on a given allocation-site are
lifespan. What is important is that these metrics are nondecreas- recompiled by the VM to implement the new object-placement pol-
ing and simple to calculate. Following common practice, we will icy. One reason to have different thresholds for changing decisions
use ages and lifespans calculated in terms of the number of bytes is to prevent the same methods from being repeatedly recompiled.
allocated. Concerning allocation-site information, we have consid- In general, though, the result of this process only affects the perfor-
ered using summary information from the allocating thread’s call mance of a running application and not its correctness.
stack. However, preliminary studies by our colleague, Tim Harris,
indicate that simply tracking the allocation-site is a sufficient dis- 4. CONCLUSION
criminator for our purposes [8]. Further, in the presence of inlining We have presented a proposal for dynamically selecting and col-
and dynamic recompilation, we have the ability to gain the bene- lecting information about object behavior in a generational frame-
fits of call stack information without incurring the cost of having to work. The proposal makes good use of facilities readily available
examine thread stacks when allocating sampled objects. in runtime systems like those provided by Java virtual machines:
We have proposed that the appropriate data structures for mak- in particular, it makes use of weak references and of the ability to
ing tenuring decisions in a configurable generational framework are dynamically recompile methods. Further, we have evidence that
histograms of either birth time or lifespan distributions. The orga- the runtime overheads for the sampling technique and data man-
nization of these histograms must have fine enough resolution to agement are low for a two-generation collector. Our plan is now to
distinguish the ages of objects in the individual generations. Fur- extend this technique to our dynamically configurable generational
ther, the distributions of ages represented by the buckets need to framework.
reflect the relative rates and frequencies with which the individual
generations are collected. One simple approximation of this might
be to scale the per-bucket distributions logarithmically. Finally, we
5. ACKNOWLEDGEMENT
must support both adaptation to changing program behavior as well We would like to thank Tim Harris for his excellent work in ap-
as some level of hysteresis to ensure that decisions, once made, are plying our methods to a two-generation system and demonstrating
stable for a while. This goal may be achieved by either periodically their practicality. In particular, his performance and tracing stud-
purging lifespan data gathered about a particular allocation site— ies, his method for graphing object lifetimes, and his idea for using
for example, when a new tenuring decision is made as to where to a small range of objects in the older generation to decide when to
place objects allocated at that site—or by “aging” the information reverse pretenuring decisions helped clarify and validate our pro-
in the histogram—for example, with the use of a decay function. posal.
In addition to Tim Harris, we would like to thank Steve Heller
3.5 Program Adaptation for many fruitful discussions. many
There are a number of ways in which lifespan information may
be used to improve the placement of objects: 6. REFERENCES
[1] A. W. Appel. Simple generational garbage collection and fast
 at allocation of an object allocation. Software Practice and Experience,
19(2):171–183, 1989.
 when promoting an object
[2] D. A. Barrett and B. Zorn. Garbage collection using a
 when moving an object within a generation dynamic threatening boundary. In Proceedings of
SIGPLAN’95 Conference on Programming Languages
All three of these decisions can be made through dynamic checks Design and Implementation, volume 30 of ACM SIGPLAN
on the available lifespan statistics of a given object. For example, Notices, La Jolla, CA, June 1995. ACM Press.
promotion of objects allocated at a given site might be improved if [3] D. A. Barrett and B. G. Zorn. Using lifetime predictors to
we know that these objects exhibit a bimodal behavior—for exam- improve memory allocation performance. In Proceedings of
ple, either dying young or living forever—and so move surviving SIGPLAN’93 Conference on Programming Languages
objects directly to the oldest generation. Design and Implementation, volume 28(6) of ACM
In the case of allocation, though, we can do better if we are SIGPLAN Notices, pages 187–196, Albuquerque, NM, June
able to recompile the methods containing the allocation sites where 1993. ACM Press.
we wish to set a particular tenuring policy. For example, the Re-
[4] Y. Bekkers and J. Cohen, editors. Proceedings of
searchVM provides mechanisms for scheduling a bytecode method
International Workshop on Memory Management, volume
to be recompiled. However, there are some cases where this is not
637 of Lecture Notes in Computer Science, St Malo, France,
possible. Examples include:
16–18 Sept. 1992. Springer-Verlag.
 the interpreter [5] P. Cheng, R. Harper, and P. Lee. Generational stack
collection and profile-driven pretenuring. In Proceedings of
 the reflection service SIGPLAN’98 Conference on Programming Languages
Design and Implementation, ACM SIGPLAN Notices,
 java.lang.Object::clone()
Montreal, June 1998. ACM Press.
The first two cases are typically not significant since objects of [6] W. D. Clinger and L. T. Hansen. Generational garbage
many types are allocated at the same site or sites. The third case collection and the Radioactive Decay model. In Proceedings
can be handled by dynamically checking the lifespan information of SIGPLAN’97 Conference on Programming Languages
for an object but it is neither a frequent case nor is it clear that there Design and Implementation, ACM SIGPLAN Notices, pages
is any relationship between the lifespan of an object and a copy of 97–108, Las Vegas, Nevada, June 1997. ACM Press.
that object. So, for our purposes, the main impact of tenuring de- [7] D. R. Hanson. Fast allocation and deallocation of memory
cisions is on dynamically compiled code and in the internal mech- based on object lifetimes. Software Practice and Experience,
anisms of the per-generation collectors. When a change in policy 20(1):5–12, Jan. 1990.
 [8] T. Harris. Dynamic adaptive pre-tenuring. In Proceedings of
the International Symposium on Memory Management, Oct.
2000.
[9] R. L. Hudson and J. E. B. Moss. Incremental garbage
collection for mature objects. In Bekkers and Cohen [4].
[10] JavaTM 2 platform, standard edition, version 1.3 api
specification. Available at:
http://java.sun.com/j2se/1.3/docs/api/index.html.
[11] R. E. Jones. Garbage Collection: Algorithms for Automatic
Dynamic Memory Management. Wiley, July 1996. With a
chapter on Distributed Garbage Collection by R. Lins.
[12] H. Lieberman and C. E. Hewitt. A real-time garbage
collector based on the lifetimes of objects. Communications
of the ACM, 26(6):419–429, 1983. Also report TM–184,
Laboratory for Computer Science, MIT, Cambridge, MA,
July 1980 and AI Lab Memo 569, 1981.
[13] D. A. Moon. Garbage collection in a large LISP system. In
G. L. Steele, editor, Conference Record of the 1984 ACM
Symposium on Lisp and Functional Programming, pages
235–245, Austin, TX, Aug. 1984. ACM Press.
[14] D. Stefanović, K. S. McKinley, and J. E. B. Moss. Age-based
garbage collection. In OOPSLA’99 ACM Conference on
Object-Oriented Systems, Languages and Applications,
volume 34(10) of ACM SIGPLAN Notices, pages 370–381,
Denver, CO, Oct. 1999. ACM Press.
[15] D. M. Ungar. Generation scavenging: A non-disruptive high
performance storage reclamation algorithm. ACM SIGPLAN
Notices, 19(5):157–167, Apr. 1984. Also published as ACM
Software Engineering Notes 9, 3 (May 1984) — Proceedings
of the ACM/SIGSOFT/SIGPLAN Software Engineering
Symposium on Practical Software Development
Environments, 157–167, April 1984.
[16] D. M. Ungar and F. Jackson. Tenuring policies for
generation-based storage reclamation. ACM SIGPLAN
Notices, 23(11):1–17, 1988.
[17] D. M. Ungar and F. Jackson. An adaptive tenuring policy for
generation scavengers. ACM Transactions on Programming
Languages and Systems, 14(1):1–27, 1992.
[18] D. White and A. Garthwaite. The GC interface in the EVM.
Technical Report SML TR–98–67, Sun Microsystems
Laboratories, Dec. 1998.
[19] P. R. Wilson. Uniprocessor garbage collection techniques. In
Bekkers and Cohen [4].
[20] B. Zorn and M. Seidl. Segregating heap objects by reference
behavior and lifetime. In Eighth International Conference on
Architectural Support for Programming Languages and
Operating Systems, San Jose, CA, Oct. 1998.