uniprocessor garbage collection techniques paul r. wilson
Post on 21-Dec-2015
230 views
TRANSCRIPT
Uniprocessor Garbage Collection Techniques
Paul R. Wilson
FromSapce/Tospace before
Ft after
Too much
3mb vs. 6mb
The Two-Phase Abstraction 1. Detection
2. Reclamation
Why Garbage Collect at All? Safety
Memory leaks Continued use of freed pointers
Simplicity
Why Garbage Collect at All? Flexibility
Hard coded program limits Efficiency!
Who is responsible for deletion? Extraneous copies
Liveness and Garbage There is a root set which is defined
as live.
Anything reachable from a live pointer is also live
Everything else is garbage
The Root Set The Root Set
Static global and module variables Local Variables Variables on any activation stack(s)
Everyone else Anything Reachable From a live value
Reference Counting Advantages
Implicitly distributes garbage collection
Real Time guarantees with deferred reclamation Keep a list of zeroed objects not yet
processed Memory efficiency, can utilize all
available memory with no work room
Reference Counting Pitfalls Conservative- needs a separate GC
technique to reclaim cycles Expensive- pointer reassignment
requires: Increment Decrement Zero Check
Stack Variables frequent creation/destruction Can be optimized to some extent
Reference Counting
Ref counting, unreclaimable
Deferred Reference Counting Defer deletion of zero counted
objects Periodically scan the stack for
pointers
Mark-Sweep Collection Starting From the root set traverse
all pointers via depth/breadth first search.
Free everything that is not marked.
Non-Copying issues Same as for traditional allocators
Fragmentation Memory block size management Locality of reference- interleaved new/old
General issues- work proportional to heap size
Copying Advantages Memory locality preserved
Disadvantages Lots of copying!
“Scavenging”
Stop and Copy How to update multiple pointers to
the same object? Forwarding Pointers
Mark/Sweep is proportional to the amount of live data. Assuming this stays roughly constant, increasing memeory will increase efficiency.
Non Copying Version Facts
Allocated with a color Fragmentation
Advantages Does not require pointer rewriting
Supports obscure pointer formats, C friendly
In place collection Conservative estimates
Useful for languages like C Pointers can be safely passed to
foreign libraries not written with Garbage Collection in mind
Incremental Tracing Collectors The ‘Mutator’ The reachability graph may change
From the garbage collectors point of view the actual application is merely a coroutine ir cuncurrent process with an unfortunate tendency to modify data structures that the collector is trying to traverse
Floating Garbage Can’t survive more than one extra round
Real Time Garbage Collection Incremental Tracing Collectors
In Place Collection Many readers single writer(mutator)
As a Copying Collector Multiple Readers Multiple Writers
Tricolor Marking White
Initial color for an object subject to collection
Black Objects that will be retained after the current
round
gray Object has been reached, but not its descendents
Wave front effect
A violation of the Coloring Invariant
Read Barrier Detects an attempt to read a white
object and immediately colors it gray
Write Barrier Traps attempts to write a pointer
into an object
Some algorithms Snapshot-at-beginning write
barrier Black-only read barrier Baker’s read barrier Dijkstra’s write Barrier Steele’s write Barrier
Baker’s Read Barrier Allocates Black Grey Objects cannot be reverted to
white Immediately Invalidates fromspace Any pointer access to fromspace
causes the GC to grey the target object by copying it to tospace if necessary and updating the pointer.
Baker’s Non Copying Scheme Real Time Friendly
Treadmill
Black Only Read Barrier When a white object in fromspace
is touched it is scanned completely.
Replication Copying Collection Until copying from from space to to
space is completed, the mutator continues to read from from space.
Write updates must be trapped to update tospace.
Single simultaneous ‘flip’ where all pointers are updated.
Expensive for standard hardware, but cheap for functional languages
Real time considerations Read Barriers add an unpredictable cost
per pointer access Nilson background scavenger, reserve only
Write barrier may be more expensive overall, but the cost per access is well bounded
Guaranteeing progress allocation clock, frees per allocation
Statically allocate troublesome objects
Results Writer barrier more efficient on
standard hardware
Snapshot at the Beginning Catches pointers which try to escape from white
objects If a pointer is replace in a black object, the
replaced pointer is first stored. All overwritten pointers are saved via a write barrier. All objects that are live at the beginning of collection
remain live Allocate Black during collection round
Incremental Update Reverts black to gray when an object is written to, or
else grays they new pointed to object
Incremental Update with Write-Barrier(Dijkstra)g
Catches pointers that try to hide in black objects Reverts Black to gray If the overwritten pointer is not
pointed to elsewhere then it is garbage
Allocated white. Newly allocated objects assumed unreachable
Motivation for a new Strategy Most objects are short lived
80% to 90% die within a few million instructions
Objects that don’t die quickly are more likely to live a while
Long lived objects are copied over and over
Excessive Paging in Scanning if the heap must exceed available physical memory
Generational Garbage Collection
Generational gc before
Generational gc after
Gc memory usage
Variations of generational collection Intergenerational references
Write barrier Old to younger Young to old
Collection Advancement policies
Advance always Advance after 2 roundsCounter in the header field?Advance always? Semispace in the last generation3 spacesBucket brigadeMark compact in the oldest generation for memory efficiency