garbage collection : Java Glossary


garbage collection
GC (Garbage Collection).

Types of Garbage Collection

  • In Canada, the government sends men to your house every every week to take away your garbage. Hoarders are free to hang onto things they don’t really need.
  • In third world countries, it is up to you to take your own garbage away.
  • Java’s garbage collection system is analogous to a garbage removal system where every hour, workers scan your house for junk mail, the contents of waste baskets, carpet lint, toenail clippings and anything else they are absolutely sure you don’t want to keep.
  • C++’s system for disposing of unreferenced objects is similar to India’s, with the strange feature that undiscarded garbage becomes invisible but still stinks.
~ Roedy (born:1948-02-04 age:68)
In Java you explicitly create new objects with new, but you don’t need to explicitly free them. From time to time the garbage collector chases all the references in all the objects to find all the live objects. Anything that can’t be reached is dead and its space in reclaimed in one fell swoop. To nearly everyone’s great surprise, the more dead objects there are, the more efficient automatic garbage collection becomes relative to the explicit schemes used in C++. Unfortunately, automatic garbage collection is not as efficient in its use of RAM (Random Access Memory) as explicit freeing because dead objects are not immediately detected. Automatic garbage collection has the big advantage you can’t screw it up.

With explicit freeing, you can accidentally free an object while some other reference is still pointing to it. Or you can forget to free it and eventually clog memory with unused objects. There is nothing to stop you from writing your own explicit free allocators in Java that recycle objects in preference to creating new ones. These sorts of custom allocator would work well when objects are a standard size, when you don’t build complex references to these objects, when the objects are short lived, when RAM is tight and/or when there are large numbers of live objects at any one time.

There are many ways of classifying garbage collectors, e.g. conservative vs. fully accurate. Conservative collection assumes everything on the stack is a pointer and tries to trace its descendants. It ends up accidentally treating ints as pointers, and needlessly locking dead objects in RAM. Fully accurate ones determine first which are pointers and which are ints and floats. There are three main problems with conservative collectors:

  1. They sometimes take longer since the fool around chasing chains of objects that are not really chains.
  2. They can cause objects to be held onto that are actually dead, thus tying up memory needlessly.
  3. They might in, pathological circumstances, corrupt memory when false objects are marked as live.

A simple mark/sweep garbage collector (such as used in JDKs (Java Development Kits) 1.0 through 1.2) pauses from time to time to collect all the garbage. This creates a quite noticeable pause from time to time. A generational collector does the work in little bits more frequently. In  Java version 1.4 or later there is an optional concurrent generational collector that takes more overhead but does not pause. You can invoke in with -XX:+UseParNewGC on the java.exe command line.

The amount of ingenuity in the design of garbage collection algorithms is astounding.

If the garbage collector cannot free up any RAM it throws an OutOfMemoryError. By this point it is usually too late to do anything.


Jove, for example, used a precise, multi-threaded, generational garbage collector. Oracle’s HotSpot claims to have an utterly state of the art garbage collector.

System.gc is very efficient if you call it when there are very few objects because it works by finding all live objects. It does not matter how many dead ones there are. There are natural breaks in an application where you have just deleted masses of objects and are just about to create a bunch more. That is the ideal time to insert a System.gc.


If you were to stop your program in mid flight, some of the objects will never be used again. Some of these, a garbage collector knows about. Some it does not. The set of all objects that will be used again are called the live objects. A supernatural being might know exactly which they were. A program that had been run previously with the exact same data with monitoring could in theory know which objects were live. A clever programmer just studying your code could predict some of them. If there were some way of perfectly determining the live objects, you could safely garbage collect the RAM from all the remaining objects, even if there were references to them. This is what C++ programmers attempt to do as daring feat of bravado every time they write a program that does manual garbage collection.

In practice you don’t know the live objects. You know the reachable objects, which are a much larger set. Consider all the Threads in your program and all the local variables in all the currently running methods in those threads. Chase all the references in the local variables to the corresponding objects. Then chase all the references in those objects. Repeat until you have found all possible objects than can be indirectly reached. These are the reachable objects you keep. Everything else gets garbage collected.

Some objects are reachable, but clearly will never be used again. Objects which are reachable and which plausibly will be used again are called active. This subtle distinction is best explained

Garbage collection has become more and more sophisticated with every release of the JVM (Java Virtual Machine). According to Thomas Pornin, posting in, generally, GC occurs by itself quite transparently. The JVM from Sun comes with several GC implementations and in most of them collection activity is split into various subtasks, some of which being able to proceed by small increments or even concurrently with the application itself. So the very notion of when GC occurs is not easy to define unambiguously.


book cover recommend book⇒Garbage Collection: Algorithms for Automatic Dynamic Memory Managementto book home
by Richard Jones, Rafael D Lins 978-0-471-94148-4 hardcover
publisher Wiley
published 1996-09-17
Expensive, but fun.
Australian flag abe books anz abe UK flag
German flag abe UK flag
German flag abe Canadian flag
Spanish flag Canadian flag
Spanish flag Chapters Indigo Canadian flag
French flag abe abe American flag
French flag American flag
Italian flag abe Barnes & Noble American flag
Italian flag Nook at Barnes & Noble American flag
India flag Kobo American flag
UN flag other stores Google play American flag
O’Reilly Safari American flag
Powells American flag
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

Learning More

Oracle’s Technote Guide on Concurrent Garbage Collection (1 CPU) : available:
Oracle’s Technote Guide on Parallel Garbage Collection (2 CPUs) : available:

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number