Internals of Java Garbage Collector

GC Responsibilities
Garbage Detection: Garbage are objects that are no longer reachable
Garbage Reclamation:Make space available to the running program again

HotSpot VM Heap Layout

SS#1: Survivor Space 1
SS#2: Survivor Space 2

How HotSpot’s GC Works

Empirical Statistics
Most objects are very short lived
– 80 – 98% of all newly allocated objects die within a few million instructions
– 80 – 98% of all newly allocated objects die before another megabyte has been allocated

Assumptions
Weak generation hypothesis
– Most new objects die young
– Concentrate effort on managing the young generation
– Make allocate/manage/deallocate cycle fast and efficient
For older objects, manage as little as possible
Keep young and old objects separate
Use different GC algorithms for each generation
– Different requirements for each group

Object Allocation

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Mawazo

Mostly technology with occasional sprinkling of other random thoughts

amintabar

Amir Amintabar's personal page

101 Books

Reading my way through Time Magazine's 100 Greatest Novels since 1923 (plus Ulysses)

Seek, Plunnge and more...

My words, my world...

ARRM Foundation

Do not wait for leaders; do it alone, person to person - Mother Teresa

Executive Management

An unexamined life is not worth living – Socrates

Diabolical or Smart

Nitwit, Blubber, Oddment, Tweak !!

javaproffesionals

A topnotch WordPress.com site

thehandwritinganalyst

Just another WordPress.com site

coding algorithms

"An approximate answer to the right problem is worth a good deal more than an exact answer to an approximate problem." -- John Tukey