garbage collection mythbusters

Download Garbage Collection Mythbusters

Post on 20-Feb-2016

79 views

Category:

Documents

1 download

Embed Size (px)

DESCRIPTION

Garbage Collection Mythbusters. Simon Ritter Java Technology Evangelist. The Goal. Cover the strengths and weaknesses of garbage collection What GC does well And what not so well. Tracing GC: A Refresher Course. Tracing-based garbage collectors: Discover the live objects - PowerPoint PPT Presentation

TRANSCRIPT

  • Garbage Collection MythbustersSimon RitterJava Technology Evangelist

    **

    The Goal

    Cover the strengths and weaknesses of garbage collection

    What GC does wellAnd what not so well

    **

    Tracing GC: A Refresher Course

    Tracing-based garbage collectors:Discover the live objectsAll objects transitively reachable from a set of roots(roots - known live references that exist outside the heap, e.g., thread stacks, virtual machine data)Deduce that the rest are deadReclaim themAn indirect GC techniqueExamplesMark & SweepMark & CompactCopying

    **

    Tracing GC Example

    BHeapCDGHIEKMJAFRuntime StackL

    **

    Tracing GC Example

    The Runtime Stack is considered live by default. We start tracing transitively from it and mark objects we reach.BHeapCDGHIEKMJAFRuntime StackL

    **

    Tracing GC Example

    BHeapCDGHIEKMJAFRuntime StackL

    **

    Tracing GC Example

    BHeapCDGHIEKMJAFRuntime StackL

    **

    Tracing GC Example

    We identified all reachable objects. We can deduce that the rest are unreachable and, therefore, dead.BHeapCDGHIEKMJAFRuntime StackL

    **

    Alternative 1: In-place Deallocation

    Keep track of the free space explicit (using free lists, a buddy system, a bitmap, etc.).HeapCHIEKLARuntime StackB

    **

    Alternative 2: Sliding Compaction

    Slide all live objects to one end of the Heap. All free space is located at the other end of the heap.HeapCHIEKLARuntime StackB

    **

    Copying GC Example

    BHeap (To-Space)CDGHIEKARuntime StackLHeap (From-Space)

    **

    Copying GC Example

    BHeap (To-Space)CDGHIEKARuntime StackLAHeap (From-Space)C

    **

    Copying GC Example

    LBHeap (To-Space)CDGHIEKARuntime StackHeap (From-Space)AHCK

    **

    Copying GC Example

    LBHeap (To-Space)CDGHKARuntime StackLIEHeap (From-Space)AHCKB

    **

    Copying GC Example

    ELBHeap (To-Space)CDGHIKARuntime StackIEHeap (From-Space)LAHCKB

    **

    Copying GC Example

    ELBCHIKAHeap (To-Space)Runtime StackHeap (From-Space)

    **

    Myth 1:

    malloc/free always perform better than GC.

    **

    Object Relocation

    GC enables object relocation, which in turn enablesCompaction: eliminates fragmentationGenerational GC: decreases GC overheadLinear Allocation: best allocation performanceFast path: ~10 native instructions, inlined, no syncfree spaceendnew topnew objecttopused space

    **

    Generational GC is Fast!

    Compare costs (first-order approximation)malloc/free:all_objects * costmalloc + freed_objects * costfreeGenerational GC with copying young generation:all_objects * costlinear_alloc + surviving_objects * costcopyConsider:costlinear_alloc much less than costmallocsurviving_objects often 5% or less of all_objects

    **

    GC vs. malloc Study

    Recent publication showsWhen space is tightmalloc/free outperform GCWhen space is ampleGC can match (or better) malloc/freeGC just as fastif given breathing roomMatthew Hertz and Emery BergerQuantifying the Performance of Garbage Collection vs. Explicit Memory Management, In Proceedings of OOPSLA 2005, October 2005

    **

    Object Relocation: Other Benefits

    Compaction: can improve page localityFewer TLB missesCluster objects to improve localityImportant on NUMA architecturesRelocation ordering: can improve cache localityFewer cache missesThe important points:Allocation and reclamation are fastRelocation can boost application performance

    **

    Myth 1:

    malloc/free always perform better than GC.

    **

    Myth 1:

    malloc/free always perform better than GC.

    **

    Myth 2:

    Reference counting would solve all my GC problems.

    **

    Reference Counting

    Each object holds a countHow many references point to itIncrement it when a new reference points to the objectDecrement it when a reference to the object is droppedWhen reference count reaches 0Object is unreachableIt can be reclaimedA direct GC technique

    **

    Reference Counting Example

    HeapCHIEKLARuntime StackMJFB

    **

    Reference Counting Example

    MJFHeapCHIEKLARuntime StackBDelete reference, Decrease H's RC

    **

    Reference Counting Example

    MJFHeapCHIEKLARuntime StackB

    **

    Reference Counting Example

    MJFHeapCHIEKLARuntime StackBDecrease K's & L's RCs, Reclaim H

    **

    Reference Counting Example

    MJFHeapCIEKLARuntime StackB

    **

    Reference Counting Example

    MJFHeapCIEKLARuntime StackBReclaim K

    **

    Reference Counting Example

    MJFHeapCIELARuntime StackB

    **

    Traditional Reference Counting

    Extra space overheadOne reference count per objectExtra time overheadUp to two reference count updates per reference field updateVery expensive in a multi-threaded environmentNon-movingFragmentationNot always incremental or promptGarbage cyclesCounts never reach 0Cannot be reclaimed

    **

    Reference Counting Example

    Objects F and J form a garbage cycle and also retain M too.MJFHeapCIELARuntime StackB

    **

    Advanced Reference Counting

    Two-bit reference countsMost objects pointed to by one or two referencesWhen max count (3) is reachedObject becomes stickyBuffer reference updatesApply them in bulkCombine with copying GCUse a backup GC algorithmHandle cyclic garbageDeal with sticky objectsTypically, the cyclic GC is a tracing GCComplex, and still non-moving

    **

    Myth 2:

    Reference counting would solve all my GC problems.

    **

    Myth 2:

    Reference counting would solve all my GC problems.

    **

    Myth 3:

    GC with explicit deallocation would drastically improve performance.

    **

    GC with Explicit Deallocation?

    PhilosophicallyWould compromise safetyPracticallyNot all GC algorithms can support itMark-Compact & Copying GCsDo not maintain free listsReclaim space by moving live objectsOverwrite reclaimed objectsNo way to reuse space from a single objectUnless the object is at the end of the heap

    **

    GC with Explicit Deallocation? (ii)

    Explicit deallocation is incompatible with this modelWould compromise the very fast allocation pathGCs have a different reclamation patternReclaim objects in bulkFree-space management is optimized for thatAlso applies to static analysis techniquesThey can prove that an object can be safely deallocatedbut there is no mechanism to do the deallocation!

    **

    How to deallocate?

    How can we deallocate the dead object when we only maintain top?topenddead objectfree spaceused space

    **

    Myth 3:

    GC with explicit deallocation would drastically improve performance.

    **

    Myth 3:

    GC with explicit deallocation would drastically improve performance.

    **

    Myth 4:

    Finalizers can (and should) be called as soon as objects become unreachable.

    **

    Finalizers

    Typical use of Finalizers:Reclaim external resources associated with objects in heape.g., native GUI components (windows, color maps, etc.)Finalizers are called on objects that GC has found to be garbageTracing GCDoes not always have liveness information for every objectLiveness information up to date only at certain pointsImmediately after a tracing cycleMust finish a tracing cycle to find finalizable objects

    **

    Finalization Reality Check

    Finalizers are not like C++ destructorsNo guaranteesWhen they will be runWhich thread will run themWhich will run first, second, lastOr that they will be run at all!If you want prompt external resource reclamationDon't rely on finalizersDispose explicity insteadUse finalization as a safety net

    **

    Reference Objects

    WeakReferences, SoftReferences, etc.Some advantages over finalizerse.g., more control over which to process, and whenSee GC-Friendly Programming slides from JavaOne 2007Yet most of the Finalization caveats applyReference objects must be queued, cleared, etc.Depending upon whether their referent is liveNot (always) a cheap question to answerWith tracing GCFew guarantees

    **

    Myth 4:

    Finalizers can (and should) be called as soon as objects become unreachable.

    **

    Myth 4:

    Finalizers can (and should) be called as soon as objects become unreachable.

    **

    Myth 5:

    Garbage collection eliminates all memory leaks

    **

    Unused Reachable Objects

    Consider the following code:class ImageMap { private Map map; public void add(File file, Image img) { map.put(file, img); } public Image get(File file){ return map.get(file); } public void remove(File file) { map.remove(file); }}static ImageMap imageMap;File f = new File(imageFileName);Image img = readImage(f);imageMap.add(f, img);f = null;

    **

    GC and Memory Leaks

    Consider the (f, img) tuple in the previous exampleAfter we null f, the tuple is unusedWe cannot retrieve it (don't have the key any more)We cannot remove it (don't have the key any more)So (f, img) will take up space while imageMap is alive without the application being able to access itGC reclaims unreachable objectsBut not unused objects that are reachableAnd it cannot know when a reachable object is unused

    **

    GC and Memory Leaks (ii)

    Effort required to track down such leaksCan't override malloc anymoreTools are needed to helpHeap population statistics (what is being retained?)Reachability information (why is it being retained?)

    **

    Myth 5:

    Garbage collection eliminates all memory leaks.

    **

    Myth 5:

    Garbage collection eliminates all memory leaks.

    **

    Myth 6:

    I can get a GC that delivers very high throughput and very low latency.

    **

    Throughput vs. Latency

    For most applications, GC overhead is small2% 5%Throughput GCsMove most work to GC pausesApplication threads do as little as possib