Garbage Collection in the Java HotSpot(tm) Virtual Machine · and how it interacts with JavaTM...

44
| J avaOne 2003 | Session 3153 Garbage Collection in the Java HotSpot™ Virtual Machine John Coomes, Tony Printezis S un Microsystems, Inc.

Transcript of Garbage Collection in the Java HotSpot(tm) Virtual Machine · and how it interacts with JavaTM...

| 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

Stop­the­World 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

Stop­the­World 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

Demo

| 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

Demo

| 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

• GC­friendly programming

• Q &A

| J avaO ne 2003 | S ess ion 3153 30

GC­Friendly 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

Demo

| 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

GC­Friendly 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

Real­World 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!)

Q&A