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