Conservative Garbage Collection - PowerPoint PPT Presentation

About This Presentation
Title:

Conservative Garbage Collection

Description:

Conservative Garbage Collection Stephan Lesch January 9, 2002 slesch_at_studcs.uni-sb.de Contents Intro Conservative GC Mostly Copying Collection Hidden Pointer Problems ... – PowerPoint PPT presentation

Number of Views:52
Avg rating:3.0/5.0
Slides: 40
Provided by: Stepha64
Category:

less

Transcript and Presenter's Notes

Title: Conservative Garbage Collection


1
Conservative Garbage Collection
  • Stephan LeschJanuary 9, 2002slesch_at_studcs.uni-sb
    .de

2
Contents
  • Intro
  • Conservative GC
  • Mostly Copying Collection
  • Hidden Pointer Problems
  • GC for C

3
So Far
  • Type-accurate GC
  • locations of pointers are known
  • no pointer arithmetic
  • often tailored to one software product
  • usually supported by compiler/runtime system

4
Ambiguous Roots Collection
  • every register/word potiential pointer
  • non-supportive environment
  • little/no knowledge about
  • register usage
  • object/stack layout
  • should work with any C/C programs
  • programmers dont want to pay for GC unless
    needed
  • must coexist with explicit memory management
  • The middle way
  • programmer/compiler provide information to
    recognize pointers

5
Conservative GC
  • Boehm/Demers/Weiser (Xerox PARC) 1988
  • non-moving mark-and-deferred-sweep collector
  • fully conservative, no reliance on compiler
  • no extra bits to distinguish pointer/non-pointer
  • no additional object headers
  • for C and C
  • for Unix, OS/2, Mac, Win95/NT
  • supports incremental/generational collection
  • can function as space leak detector

6
Heap Layout
  • Two logically distinct heaps
  • Standard heap
  • malloc / free
  • compatible with existing code
  • no pointers to collected heap!
  • Collected heap
  • GC_malloc
  • GC_free to free known garbage
  • pointers to standard heap ignored

7
Layout of Collected Heap
  • made up of blocks (e.g. 4 K, aligned to 4 K
    boundaries)
  • one object size per block
  • for each object size
  • bitmap to mark allocated objects
  • freelist (linked list of heap block slots)
  • reclaimable blocks queue (deferred sweep)
  • heap-block free-list

8
Finding headers bit maps
9
Allocation
for objects gt 1/2 block allocate chunk of
blocks(heap-block free list) none available
GC not enough space reclaimed expand
heap
for small objects pop free-list for this
size free-list is empty resume sweep
phase still empty GC not enough
space reclaimed expand heap
Clear object after allocation!
10
Finding Roots Pointers
  • possible roots registers, stack, static areas
  • no cooperation from compiler
  • treat every word as potential pointer
  • ignore interior pointers (standard)
  • prefer marking from false pointers over ignoring
    valid pointers
  • Conservative Pointer Identification given word
    p
  • does p refer to the collected heap?
  • does it point into heap block allocated by
    collector?
  • does it point to the beginning of an object in
    that block?
  • if yes,
  • mark object in block header
  • push object onto mark stack
  • finally reset mark bits of objects on free-lists

11
Misidentification
  • integers accidentally fulfilling validity tests
  • avoid need to trace from interior pointers...
  • ... or unaligned pointers 000000090000000A
  • avoid addresses with lots of trailing 0s
  • try to avoid generating false references
  • collector clears non-atomic objects after alloc
  • GC_malloc_atomic for objects without pointers
  • programmer initialize structures
  • programmer destroy obsolete pointers (dead
    pointers on stack are often the most significant
    source of leaks)

12
Black Listing
  • Idea dont allocate in heap blocks at addresses
    likely to collide with invalid pointers
  • black list references to vincinity of heap which
    fail validity tests
  • extra run before first allocation finds false
    references in static data
  • additional space overhead lt 10
  • but difficult to allocate gt100K without spanning
    black-listed blocks

13
Influence of Data Structures
  • Problems with
  • large structures interior pointers
  • strongly connected structures
  • Lisp
  • small disjoint garbage structures
  • lists constructed of cons-cells
  • gt Conservative GC worked well, memory leaks
    remain bounded (lt8 leakage, constant amount)
  • KRC
  • large, strongly connected structures
  • next pointers in objects
  • gt collector thrashed
  • Wentworth, 1990

14
Efficiency (1)
  • Comparative studies by Zorn, 1992 Detlefs et al.
    1994
  • real-world C programs (perl, xfig,
    GhostScript)
  • comparing BDW w. explicit managers
  • replace malloc() w. GC_malloc(), remove free()
  • no further adaption
  • used outdated versions (4.3 vs. 1.6/2.6)

15
Efficiency (2)
  • realistic alternative to explicit mem
    management(20 avg execution time overhead over
    best managers, up to 57 in worst case)
  • marks 3 MB/s on SparcStation II
  • up to 3 times heap usage for small heaps (fixed
    cost for collectors internal structs)
  • needs substantially more space to avoid
    over-frequent GC
  • works best w. programs using very small objects
  • might co-exist poorly with cache management(heap
    blocks aligned on 4K boundaries)

16
Incremental/Generational Mode
  • marking in small steps interleaved with mutator
  • need to detect later changes to connectivity in
    traced parts of graph
  • read dirty bits for pages
  • write-protect memory and catch faults
  • when mark stack is emptytrace from all marked
    objects on dirty heap blocks
  • reduces avg. pause times, increases total exec
    time
  • generational GC uses knowledge which pages were
    recently modified

17
Mostly Copying Collection
  • Joel Bartlett, 1988 (Digital)
  • hybrid conservative / copying collector
  • roots are treated conservative (dont move
    referenced objects)
  • objects only accessible from heap-allocated
    objects are copied(assumes pointers in
    heap-allocated data can be found accurately)
  • faster allocation less problems with pointer
    identification
  • more accurate GC

18
Object layout
header
size
pointers
pointers
user data
non-pointers
  • programmer has no control over object layout
  • what if object layout should match hardware
    registers or file structures?

19
Heap layout
blocks with space identifiers
root
  • current_space 1
  • next_space 1

0
1
currently unused
1
42
currently unused
20
Allocation
  • within a block
  • inc free-pointer
  • dec free-slots-count
  • if necessary search for free block
  • (space_id ? current_space/next_space)
  • set its space_id to next_space
  • current_space next_space during allocation

21
Collection
  • GC when heap is half full (half of heap blocks
    have space_idcurrent_space)
  • next_space current_space 1 mod n
  • Fromspace current_space blocks
  • Tospace next_space blocks
  • scan roots conservatively for pointers into heap
  • move potentially referred objects to Tospace
  • changing space_id of their blocks to next_space
  • add block to Tospace scan list
  • copy graphs accessible from blocks on scan list

22
Heap after Collection
root
  • current_space 2
  • next_space 2

2
2
1
42
currently unused
currently unused
23
Bartletts GC algorithm (1)
  • gc()
  • next_space (current_space 1) mod 077777
  • Tospace_queue empty
  • for R in Roots
  • promote(block(R))
  • while Tospace_queue ! empty
  • blk pop(Tospace_queue)
  • for obj in blk
  • for S in Children(obj)
  • S copy(S)
  • current_space next_space

24
Bartletts GC algorithm (2)
  • promote (block)
  • if Heap_bottom ? block ? Heap_top
  • and space(block) current_space
  • space(block) next_space
  • allocatedBlocks allocatedBlocks 1
  • push(block, Tospace_queue)
  • copy (p)
  • if space(p) next_space or p nil
  • return p
  • if forwarded(p)
  • return forwarding_address(p)
  • np move(p, free)
  • free free size(p)
  • forwarding_address(p) np
  • return np

25
Generational Mode (1)
  • One bit in space_id indicates young/old
    generation
  • Other bits approximate age of objects/blocks
  • Minor collection
  • when 50 of free space after last GC is full
  • young objects reachable from roots/remembered set
    are promoted en masse (change space_id/copy)
  • remembered set maintained via memory protection

26
Generational Mode (2)
  • Major collection (mark-compact)
  • when old generation occupies gt85 of heap
  • mark accessible objects in old generation
  • pass 1 find old generation blocks lt1/3
    filledcopy objects to free space leaving
    forwarding addresses
  • pass 2 rescan old generation, correct pointers
    using forwarding addresses
  • expand heap if gt75 full
  • maintaining remembered set costs time, but often
    saves more time during GC(20 time improvement
    on Scheme compiler)also reduces pause times in
    interactive programs

27
Efficiency (1)
  • no thorough studies
  • space overhead space_ids, type info, block
    links, promotion bits 2 for 512 byte blocks
    tagging data increases overhead
  • Mostly Copying vs. BDWMostly Copying probably
    better with many shortlived objects, benefit from
    faster allocation

28
Experiences
  • generational version 20 runtime improvement for
    Scheme-to-C compiler
  • significant performance increase in CAD program
    (reduced paging)
  • bad results for non-generational collector for
    Modula-2 w. very large heaps (10s of Megabytes)
  • choose GC strategy that fits behaviour of mutator

29
The optimising Compiler/User Devil
  • conservative GC defeated by temporarily hidden
    pointers - parts of graph may be unreachable
    during a GC
  • pointer arithmetic
  • adding tag bits
  • e.g. optimized array traversal

xend xSIZE for( xltxend x) ...x... x -
SIZE ...x...
for (i0 iltSIZE i) ...xi... ...x...
inside loop x is interior pointer, afterwards x
points one past the end
30
Machine-specific Optimizations
  • struct l_thing
  • char thing35000
  • struct l_thing next
  • struct l_thing
  • tail(struct l_thing x)
  • return (x-gtnext)
  • on IBM RISC System/6000, tail() translates to
  • AIU r3r3,1 r365536
  • L r3SHADOW(r3, -30536) r335000
  • BA lr

31
Boehm and Chases Solution (1)
  • local root set of function f at any point in
    execution
  • register/auto variables
  • previously computed values of direct
    sub-expressions of incompletely evaluated
    expressionsmallocs return value in
    malloc(size) 4
  • global root set
  • declared static and extern variables
  • local root sets of all call sites in call chain
  • any values stored in other areas scanned by
    collector
  • valid base pointer
  • pointer to anywhere inside an object or one past
    its end
  • BDW can handle such pointers

32
Boehm and Chases Solution (2)
  • every object on garbage collected heap must be
    accessible from global root set through chain of
    base pointersconservative collection safe with
    strictly ANSI-compatible programs
  • suggested implementation
  • preprocess source using macros that prevent code
    generator from discarding live base pointers
    prematurely
  • compile normally
  • post-process assembly code, removing macro
    artifacts
  • transparent to programmer compiler
  • may interfere with instruction scheduling
  • may increase register pressure

33
Ellis and Detlefs solution
  • annotate operations on pointers with names of
    base pointers from which theyre derived
  • compiler treats these operations as uses of the
    original base pointers, extending their live
    ranges
  • code generation must respect live ranges
  • requires changes to compiler
  • does not alter sources
  • does not rely on behaviour of volatile
    declarations

34
GC for C
  • object-oriented languages often use more
    heap-allocated data
  • generate more complex data structures
  • GC uncouples memory management from class
    interfaces instead of dispersing it through code

35
Conservative GC for C
  • requires no changes to language
  • restriction on coding style holds no hidden
    pointers (converted to int)
  • existing code may violate the restriction
  • aggressive optimisers may as well
  • safety must be enforced in code-generator
  • some support for finalization (GC_register_finaliz
    er) - assuming few objects need finalization

36
Mostly Copying for C
  • storing all pointers at beginning of objects
    interferes with inheritance (fast field lookup)
  • here user supplies callback methods to identify
    pointers

class Tree public Tree left Tree
right int data Tree (int x) GCCLASS(Tree)
...
GCPOINTERS(Tree) gcpointer(left) gcpointer(ri
ght)
GCPOINTERS macro generates callback method
TreeGCPointers
  • currently no support for finalisation

37
Benefits of pointer locating methods
  • programmer may solve unsure reference
    problemunion int n thing ptr x
  • enables semantically accurate markinge.g.
    stacks, queues
  • automatic GC retains uncleared references to
    removed elements
  • programmer can omit them
  • even better than type-accurate GC

38
Using Object Descriptors
  • Detlefs, 1991 extension to Mostly Copying
  • insert descriptor into object headers
  • Bitmap format
  • 1 word with 32 bits indicating pointer/non-pointer
    words
  • use if only first 32 words of user data contain
    pointers, cant handle unsure references
  • Indirect format
  • pointer to byte array encoding sure/unsure
    references and non-pointer values
  • array can be compressed using repeat counts
  • Fast indirect format
  • array of ints 1st number indicates repetitions
    of rest
  • subsequent numbers number of words to skip to
    reach next pointer, negative number indicates
    unsure reference

39
Conclusion
  • GC effective for traditional imperative languages
  • realistic alternative to explicit mem management
    for most applications
  • not yet suitable for real-time / safety-critical
    applications
  • no big onstraints to coding style, except hidden
    pointer problem
  • gcing allocators competitive even with code not
    written for GC
  • GC should have hooks for client/programmer to
    communicate their knowledge
  • explicit deallocation calls
  • atomic objects
  • hints of appropriate times to collect
Write a Comment
User Comments (0)
About PowerShow.com