Upload
dangtuyen
View
217
Download
1
Embed Size (px)
Citation preview
| J avaO ne 2003 | S ess ion 3153
Garbage Collection in the Java HotSpot™ Virtual Machine
John Coomes, Tony Printezis
S un Microsystems, Inc.
| J avaO ne 2003 | S ess ion 3153 2
Presentation Goal
Help you understand garbage collection and how it interacts with J avaT M programs, so you can make informed choices when des igning, developing, and deploying your applications
| J avaO ne 2003 | S ess ion 3153 3
Speaker’s Qualifications
• John Coomes is a S taff E ngineerat S un Microsystems
• C urrently works on garbage collection in the HotS pot™ virtual machine
• Has worked on various parts of J ava™ 2 P latform, S tandard E dition™ for~5 years ;3 years on HotS pot
• E njoys mountain biking
| J avaO ne 2003 | S ess ion 3153 4
Speaker’s Qualifications
• Tony Printezis is a member of the J ava™ T echnology R esearch G roup at S un Microsystems L abs
• P revious ly a faculty member in the D ept. of C omputing S cience at the Univers ity of G lasgow, S cotland
• Has been working on G C for~5 years ;wrote the firs t vers ion of the mostly- concurrent collector
• D oesn’t enjoy mountain biking
| J avaO ne 2003 | S ess ion 3153 5
What We’re Trying to Sell...
Garbage collection is your friend
Finalization is not
| J avaO ne 2003 | S ess ion 3153 6
Agenda
• A utomatic memory management—what, why
• G arbage collection characteris tics
• G arbage collection in HotS pot
• G C - friendly programming
• Q &A
| J avaO ne 2003 | S ess ion 3153 7
What Is AutomaticMemory Management?
• O bject allocation─ new operation
• G arbage collection (G C )─ R eclaim unused memory─ C lass unloading─ Weak reference process ing, finalization─ L ayout of object heap
Application GCObject Heap
| J avaO ne 2003 | S ess ion 3153 8
Why AutomaticMemory Management?
• Makes programs s impler─ R emoves need for explicit deallocation─ P revents memory leaks─ S implifies interface to data types─ E nables proper encapsulation
• E nables programming language safety─ P revents dangling pointers
| J avaO ne 2003 | S ess ion 3153 9
Agenda
• A utomatic memory management—what, why
• Garbage collection characteristics
• G arbage collection in HotS pot
• G C - friendly programming
• Q &A
| J avaO ne 2003 | S ess ion 3153 10
GC Design Goals
• F ast, fas t, fast allocation
• P rompt reclamation of unused memory
• Minimal dis ruption of running application─ S mall, predictable pauses
• L ow overhead (space, time)
• S calable to large object heaps
| J avaO ne 2003 | S ess ion 3153 11
GC ‘Facts of Life’
• A lgorithm and policy trade-offs─ Heap s ize vs . collection time overhead─ P ause time vs . application throughput
• S ince one s ize doesn’t fit all...─ O ffer choices─ Use adaptable, self-adjusting algorithms
| J avaO ne 2003 | S ess ion 3153 12
GC Characteristics
• P artial collection vs . full collection
• S top- the-world vs . concurrent
• S erial vs . parallel
| J avaO ne 2003 | S ess ion 3153 13
Partial Collection vs. Full Collection
• P artial collectionC ollect sub- regions of heap independently+ E xploit object lifetimes, garbage dens ities
• More memory reclaimed per unit of G C work– Must track references into collected area
• Write barrier● Slight impact on execution time
• J IT compiler must cooperate
collected uncollected
heap
| J avaO ne 2003 | S ess ion 3153 14
Partial Collection vs. Full Collection
• F ull collectionC ollect entire heap each time– P ause times longer
• P roportional to heap s ize
+ No write barrier, s impler implementation
collected
heap
| J avaO ne 2003 | S ess ion 3153 15
StoptheWorld vs. Concurrent
• S top- the-world G CA ll G C work done while application stopped+ O bject graph frozen during G C– L onger pauses
• C oncurrent G CMost G C work done while application running– O bject graph changing during G C
• S ynchronization required, more complex
– F ootprint may be larger (“floating garbage”)+ S horter pauses
| J avaO ne 2003 | S ess ion 3153 16
Serial vs. Parallel
• S erial+ S impler algorithms– E xtra C P Us (> 1) idle during G C– G C longer in wall- clock time
• P arallel– S ynchronization required, more complex+ Uses multiple C P Us for G C+ G C shorter in wall- clock time
| J avaO ne 2003 | S ess ion 3153 17
Agenda
• A utomatic memory management—what, why
• G arbage collection characteris tics
• Garbage collection in HotSpot
• G C - friendly programming
• Q &A
| J avaO ne 2003 | S ess ion 3153 18
GC in HotSpot
• F ast allocation
• P artial collections─ G enerational
• S top- the-world, or mostly concurrent1
• S erial, or parallel1
1A vailable, but not enabled by default
| J avaO ne 2003 | S ess ion 3153 19
Fast Allocation
• New objects allocated in “nursery”─ Nurseries are often thread- local─ L arge objects may be allocated elsewhere
• A llocation: update a s ingle pointer─ Usually inlined by compilers
• new java.lang.Object()is about 10 native instructions
• F ast allocation enabled by G C
| J avaO ne 2003 | S ess ion 3153 20
StoptheWorld GC in HotSpot
• V M tracks thread state─ R unning compiled bytecodes─ Interpreting bytecodes─ R unning native code─ Waiting on lock
• O nly threads executing bytecodesare s topped─ T hreads in native code continue to run
• S ome collection work can be concurrent
| J avaO ne 2003 | S ess ion 3153 21
Partial GC in HotSpot
• Weak generational hypothes is :─ Most objects are short- lived─ F ew references from old to young objects
• Y oung generation: nursery─ F requent collections─ S horter duration
• O ld generation: objects that survive one or more G C s─ Infrequent collections─ L onger duration
Heap divided into “generations”
| J avaO ne 2003 | S ess ion 3153 22
Young Generation in HotSpot
• Most objects are short- lived─ B orn, live, die in young generation
• C opying collector─ Most efficient when garbage ratio is high
• S erial and parallel collection policies─ D efault is serial G C
Top
“from” space
Object “nursery”
“to” space
| J avaO ne 2003 | S ess ion 3153 23
Parallel GC in HotSpot
• P arallel young generation collection─ T akes advantage of multiple C P Us─ Improves throughput, pause times─ S cales to large heap s izes─ L oad balancing done via work s tealing─ C ustomer quote:
“T he best V M enhancement I’ve seen in years”
• E nabled with -X X :+UseP arallelG C
• O ld generation collection done serially
| J avaO ne 2003 | S ess ion 3153 25
Concurrent Collection in HotSpot
• Mostly- concurrent old generation collector─ C oncurrent Mark-S weep, or C MS─ B ulk of G C done while application running
• S hort pause times─ O ld generation objects not moved
• A llocation more than bumping a pointer
• E nabled with -X X :+UseC oncMarkS weepG C
• Y oung generation G C─ P arallel used by default if C P Us available
| J avaO ne 2003 | S ess ion 3153 26
Concurrent Collection in HotSpot
xest
C oncurrent Mark S weep P hases
J ava thread
G C thread
C P U 1
C P U 2
C P U 3
C P U 4
C P U 5
C P U 6
C P U 7
C P U 8
Initi
al M
ark
Co
ncu
rre
nt
Ma
rk
Re
ma
rk
Co
ncu
rre
nt
Sw
ee
p
| J avaO ne 2003 | S ess ion 3153 28
Future Enhancements
• G C tuning needed for best performance─ Moving toward self- tuning V M─ T uning guide available
• http://java.sun.com/docs/hotspot/
• Better observability─ J S R 174 Monitoring and Management
• C oncurrent collector─ More parallelism, more concurrency─ S horter pauses
| J avaO ne 2003 | S ess ion 3153 29
Agenda
• A utomatic memory management—what, why
• G arbage collection characteris tics
• G arbage collection in HotS pot
• GCfriendly programming
• Q &A
| J avaO ne 2003 | S ess ion 3153 30
GCFriendly Programming
• F inalization
• O bject pools
• O ther things to cons ider
| J avaO ne 2003 | S ess ion 3153 31
What Is Finalization?
• A cleanup hook for external resources─ F ile descriptors─ Native G UI s tate
• A class overrides• protected void finalize() { ... }
─ A t some unspecified time after objectbecomes unreachable
─ finalize() may be invoked
| J avaO ne 2003 | S ess ion 3153 32
How Does Finalization Work?
E ach instance 1. Is registered when allocated2. Is enqueued when it becomes unreachable3. Has the finalize() method invoked4. B ecomes unreachable again (if resurrected in s tep 3)5. Has the s torage reclaimed
new GC Finalizer GC
| J avaO ne 2003 | S ess ion 3153 34
Impact of Finalization
• E xecution speed ─ S lower allocation─ F inalizer thread affects scheduling
• Heap s ize─ Memory retained longer
• C ollection pauses─ D iscovery and queuing
| J avaO ne 2003 | S ess ion 3153 35
GCFriendly Finalization
• Use for cleanup of external resources
• S uggestions─ L imit the number of finalizable objects─ R eorganize classes so finalizable object
holds no extra data─ B eware when extending finalizable objects
in s tandard libraries─ G UI elements , nio buffers
• A lternatives─ Use java.lang.ref.WeakReference
without finalizers
| J avaO ne 2003 | S ess ion 3153 36
Object Pools
• Manual memory management─ A llocation serialized─ C urrent collectors support parallel allocation
• D ata is kept artificially alive─ A dds pressure on garbage collector
• Breaks down abstract data types─ Who is respons ible for instances?
• Use only if allocation or initialization is expens ive
| J avaO ne 2003 | S ess ion 3153 37
Object Pool Example
• class Node { private static Node head = null; private Node next;
public static synchronized Node allocate() { if (head == null) return new Node(); Node result = head; head = head.next; return result; } public static synchronized void free(Node n){ n.next = head; head = n; } ...}
| J avaO ne 2003 | S ess ion 3153 38
RealWorld Problem
• O bject pools never truncated
• P eak live data ~300MB
• A verage live data ~100MB
• P roblem─ O ther garbage generated from libraries─ G C s less frequent, but dealt with 300MB
• S olution─ R emoved object pools ; application ran faster
| J avaO ne 2003 | S ess ion 3153 39
Other Things to Consider
• S ize heap appropriately─ Maximum should be larger than working set
… but smaller than available phys ical memory─ L eave room for the system to adapt
• A void java.lang.System.gc()
• T ry different collection algorithms─ -X X :+UseP arallelG C─ -X X :+UseC oncMarkS weepG C
| J avaO ne 2003 | S ess ion 3153 40
Summary
• G C s implifies J ava™ programs
• S everal types of G C─ S erial, parallel, concurrent, ...─ E ach suited to a subset of applications─ HotS pot provides choices
• A void finalization, object pooling─ Use only as a las t resort
| J avaO ne 2003 | S ess ion 3153 41
What We Hope You Bought ...
Garbage collection is your friend─ Or at least it can be
| J avaO ne 2003 | S ess ion 3153 42
What We Hope You Bought ...
Garbage collection is your friend─ Or at least it can be
Finalization is not─ Or at least it may not be (you just don’t know!)