garbage collection : Java Glossary

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 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 JDK 1.4+ there is an optional concurrent geneartional 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.

Methods you may find useful:

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.

Terminology

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 by an example:

Books

	recommend book⇒Garbage Collection : Algorithms for Automatic Dynamic Memory Management
		hardcover
	ISBN13:	978-0-471-94148-4
	ISBN10:	0-471-94148-4
	publisher:	John Wiley & Sons
	published:	1996-09-17
	by:	Richard Jones, Rafael D Lins
Expensive, but fun.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com abe books anz

Learning More