the metronome washington university in st. louis tobias mann october 2003
DESCRIPTION
Overview Garbage Collection Techniques What is the Metronome Segregated Free List Tri-Color Marking Read Barrier Copying Algorithm Write Barrier Snapshot-in-the-beginning Stack processing Scheduling User must supply QuestionsTRANSCRIPT
The Metronome
Washington University in St. LouisTobias Mann
October 2003
Developers
IBM T.J Watson Research Center David F. Bacon Perry Cheng V.T. Rajan
A Real-time Garbage Collector with low Overhead and Consistent Utilization. Jan 2003
Controlling Fragmentation and Space Consumption in the Metronome, a Real-time Garbage Collector for Java. June 03
Overview Garbage Collection Techniques What is the Metronome Segregated Free List Tri-Color Marking Read Barrier Copying Algorithm Write Barrier Snapshot-in-the-beginning Stack processing Scheduling User must supply Questions
Garbage Collection Techniques One can classify garbage collection
algorithms into two categories Copying collectors
Copies live objects to a reserved portion of memory Non-copying collectors
Dead objects are marked and collected using various techniques
Copying collectors use extra memory but prevents external fragmentation
What is the Metronome?
A garbage collector implemented in Jikes RVM that is: A mostly non-copying hybrid
An incremental uniprocessor collector targeted at embedded systems Concurrent but not parallel
Segregated Free List Memory is divided into pages of a fixed size (may
differ from the OS page size)
Each page is divided into fixed sized blocks
Geometric progression of block sizes Si = Si-1 (1 + ρ) Choose ρ = 1/8
Worst case internal fragmentation of 12.5%
ρ = 0 would mean that all blocks are the same size ρ = 1 would be the buddy system
Segregated Free List cont.
Segregated Free List is kept as a chain of pages. Each page has an associated mark array Allocation cursor pointing to both a page and a
block When a list is empty a new page is chosen
and broken up into blocks of appropriate size How is a new page chosen?
Tri-Color Marking White = Untouched by collector (considered dead at the end of collection) Grey = Touched but not scanned Black = Scanned Tri-color invariant – No black object can hold a pointer directly
pointing to a white object
Problem
Tri-Color Marking cont.
Metronome allocates black
Weak tri-color invariant
Read and Write Barrier
Problem
Problem
Read and Write Barrier cont.
Read Barrier Detects when the mutator attempts to access a
pointer pointing to a white object and immediately colors that object grey. (Wilson 1995)
Write Barrier Detects when the mutator attempts to write a
pointer into an object and traps or records the write. (Wilson 1995)
Read Barrier Brooks-style read barrier
To-space invariant mutator only sees objects in to-space
Forwarding pointer
From-space To-space
Read Barrier cont.
Eager Barrier Register and stack cells always point into to
space
Forwarding is performed “eagerly” as soon as quantity is loaded
Read Barrier cont.
The collector handles all the work of finding and moving objects
This circumvents the problem of uneven utilization suffered by other implementations of a to-space invariant How does this solve the under utilization issue
that is claimed to be endemic to implementations of to-space invariants?
Copying Semispace
Root set
A B
C D
free
from-space
to-space
B C DA
scan scanscan freefreefree
Copying cont. Copying is only performed when
defragmentation is needed If nr of free pages < threshold
Perform defragmentation
Threshold is the smallest nr of free pages that allows the mutator to execute for another collection cycle
Determined at the end of each sweep phase
Copying cont.for each page compute the nr of live objects
for each free list sort pages by occupancy
while the target nr of pages to evacuate in this size class has not been met AND there are pages left to defragment move objects form the least occupied to the most occupied pages within a list
Target nr of pages is chosen so that the sum of the current nr free pages and target is sufficient for two collection cycles
Write Barrier If the mutator attempts to overwrite a pointer,
the overwritten value is pushed onto the marking stack for later examinationRoot set
Marking stack
Problem
Solution
Weak tri-color invariant
Snapshot-in-the-beginning
Metronome’s non-copying algorithm Similar to Yuasa’s snapshot-at-the-beginning
Weak tricolor invariant Extent mark phase to also handle forwarding by
redirecting any pointers pointing into from-space so they point into to-space. Objects relocated during the previous collection can now
be freed. This maintains the eager read barrier previously
mentioned
Snapshot-in-the-beginning cont. Conceptually this algorithm takes a
“snapshot” of the graph of reachable nodes in the beginning of collection
This conceptual snapshot is maintained by the write barrier
Snapshot-in-the-beginning cont. The objects considered live is the set union of
the set of objects that are live when collection starts and the set of objects that are allocated during collection
Floating garbage
Stack processing Not incremental
Two parts root scanning maintenance of eager invariant for read barrier
How does this affect real-time performance? Stop the world while register and stack cells are
forwarded?
For java why not perform forwarding method by method on demand? Method A calls method B, forward references in A when B
returns
Scheduling
Time-based
Work-based
Are time-based and work-based scheduling different if allocation rate is known?
User must supply Max live Max allocation rate
Proportion of memory devoted to the heap (as supposed to thread stacks)
Lower bound on average object size Lower bound on nr of pointers per word (object) Upper bound on the fraction of non-null references
The last four is needed to calculate the time required to perform a collection at time, t. TGC(t) = TI + TR(t) + TM(t) + TS(t) + TD(t)
Would not the lower bounds simply be 0? Can the nr of pointer per word be anything but 0 or 1?
Questions Segregated Free List
How is a new page “chosen” when a free-list is empty?
Why is this considered together with garbage collection? Is not the maintenance of the free list the responsibility
of the allocator?
Questions cont. Is the only difference between the Metronome Mark
and Sweep and Yuasa’s algorithm that the Metronome does forwarding during the mark phase?
How does the above property solve the under utilization problem that is claimed to be endemic to implementations of to-space invariant?
How is list of grey objects maintained? a separate data structure? (Yuasa uses a stack) objects linked together in memory?
Questions cont.
How does the fact that stack processing is not incremental effect real-time performance?
Stack processing is not incremental. Does this mean that Metronome must “stop the world” while register and stack cells are forwarded to maintain the eager invariant?
For java why not perform forwarding method by method on demand? A calls B, forward references in A when B returns
Questions cont. The paper claims that copying algorithms that
attempt to collect a subset of the heap at a time can be defeated by an adversarial mutator. Why is that the case? Kelvin Nielsen claims his collector performs very
well performing copying on a subset of the heap and mark-sweep on the remaining part of the heap.
Questions cont.
How is from- and to-space distinguished? Since copying algorithm only moves objects
between pages within a free list how is from- and to-space separated?
Are time-based and work-based scheduling different if allocation rate is known?
Is not the lower bounds for objects per word and average object size just 0?
Can the nr of pointer per word be anything but 0 or 1?
Questions cont.
Is it really necessary to consider defragmentation while proving the real-time capabilities of a collector? If one assumes that each free list has size = max
live then garbage collection will still be needed but defragmentation is a non issue.
References Bacon, F. D., Cheng, P., and Rajan, V. T. A Real-time Garbage Collector
with Low Overhead and Constant Utilization. Jan 2003
Bacon, F. D., Cheng, P., and Rajan, V. T. Controlling Fragmentation and Space Consumption in the Metronome, a Real-time Garbage Collector for Java. June 2003
Nielsen, K. Doing Firm-Real-Time With J2SE APIs. July 2003
Wilson, R. P. Uniprocessor Garbage Collection Techniques 1995