 |
|
||
|
|
Visualworks GC Theory |
|
Taken from material found in the Image
I. Overview
Our language implementation sits atop a
hybrid memory manager
consisting of the following garbage-collection subsystems:
A Generation Scavenger
An Incremental, Mark-Sweep Garbage Collector
A Compacting, Mark-Sweep Garbage Collector
A Global, Compacting Garbage Collector
Our basic garbage-collection philosophy
is that most applications
consist of multiple object populations, each of which is distinguished
by certain demographic characteristics that are not shared with
the
other object populations. No known garbage-collection scheme is
capable of catering to these demographic differences equitably.
Accordingly, our memory manager employs a different garbage-collection
scheme for each of the object populations that occur in the typical
Smalltalk application.
Ephemeral Objects -- Generation Scavenger
Session-Specific Objects -- Incremental Garbage Collector
Long-Lived Objects -- Compacting Garbage Collector
Quasi Permanent Objects -- Global Garbage Collector
II. Garbage-Collection Overhead
The system's prime reclamation system --
the generation scavenger -- is
designed to add minimal overhead to an application's throughput.
By
default, it is tuned to add ~3-5% overhead to the typical application
(see the scavenging papers below). Your mileage may vary, of course.
However, the programmer can tune the scavenger to take more or
less
overhead (e.g., scavenge overhead can be decreased by increasing
the
size of the space in which objects are created).
The scavenger does not slow down as more
objects are created, because
it only handles those objects housed in NewSpace. A large volume
of
objects created during a given session will, however, require
the
incremental garbage collector (IGC) to work harder. The IGC can
be
tuned programmatically as well (see the documentation referenced
below). How much overhead the IGC adds to a given computation
is
application-specific, of course.
III. Scalability
In principle, there are no hard limits on
the size of an object, the
number of objects that you can have, the total volume of all objects
in
an image, etc. However, there may very well be practical limits
that we
haven't encountered to date. Our implementation was designed to
accomodate images in the range of 1-10-20 mbytes, simply because
that
was roughly the memory footprint that host-platform configurations
could accomodate at the time the current implementation was designed.
We went to great effort to eliminate any artificial limitations
in the
hopes that programs could scale up beyond that level without suffering
performance bottlenecks. In fact, users have reported using images
approaching 100 mbytes in size. However, it is an industry rule
of
thumb that no design, however well conceived, can be expected
to scale
up by a factor of ten and still operate efficiently.
This is not to say that it is categorically
impossible to achieve
adequate performance while working at such a scale. In fact, we
have
taken the following measures to make it possible for sophisticated
systems programmers to effectively modify the base system to achieve
such performance (not that there is any guarantee that such measures
allow one to achieve adequate performance in all cases):
1. Any part of the base Smalltalk system
can be modified,
including all fundamental classes, data structures, and
algorithms.
2. The Virtual Machine's various caches
(e.g., the
CompiledCodeCache, the StackSpace, the sizes of NewSpace, etc.)
can be reconfigured for performance purposes.
3. The user can modify or rewrite any of
the memory manager's
policies controlling the configuration and growth of object
memory, the manner in which all of the VM's reclamation systems
are run (e.g., the scavenger, the incremental garbage
collector, the compacting garbage collector), and the handling
of low-space conditions.
IV. Publications and Papers
A. Memory Manager Overview
1. Memory Management Chapter -- VisualWorks Users Guide
2. Reclamation
Facilities Overview
See -- ObjectMemory(class)>>reclamationFacilities
3. Memory
Space Overview
See -- ObjectMemory(class)>>spaceDescriptions
B. Generation Scavenger
1. Ungar D. and Jackson F. "An
Adaptive Tenuring Policy for
Generation Scavengers." Transactions on Programming Languages
and Systems, Vol. 14, No. 1, January 1992, Pages 1-27.
2. Ungar D. and Jackson F. "Tenuring
Policies for Generation-Based
Storage Reclamation." Proceedings of the ACM Conference on
Object-Oriented Programming, Systems, Languages and
Applications. San Diego, California. September 25-30. 1988.
3. Jackson F. "Generation Scavenging
-- An Efficient, Unobtrusive,
Portable Garbage Collector." Dr. Dobbs Journal #164. May
1990.
C. Garbage Collection Latency in Smalltalk
D. Weak Pointers & Finalization
1. WeakArrays & Finalization Chapter -- VisualWorks Users Guide
2. Internal Finalization Document
