Java Glossary : garbage collection

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : G words : garbage collection.

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 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:

They sometimes take longer since the fool around chasing chains of objects that are not really chains.
They can cause objects to be held onto that are actually dead, thus tying up memory needlessly.
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.

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

Garbage Collection : Algorithms for Automatic Dynamic Memory Management

0-471-94148-4

Richard Jones, Rafael D Lins

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:

Runtime r = Runtime.getRuntime();

// amount of unallocated memory
long free = r.freeMemory();

// total amount of memory available allocated and unallocated.
long total = r.totalMemory();

// total amount of allocated memory
long inuse = r.totalMemory() - r.freeMemory();

// max memory JVM will attempt to use
long max = r.maxMemory();

// suggest now would be a good time for garbage collection
System.gc();

Jove, for example, uses a precise, multi-threaded, generational garbage collector. Sun's HotSpot claims to have a 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.

Artima Types of GC ¤ Artima Under The Hood ¤ Concurrent garbage collection in Sun's JVM (Option: -Xconcgc) ¤ Demon links ¤ Garbage collection FAQ ¤ Garbage Collection Links ¤ Mark-and-sweep ¤ packratting ¤ Richard Jones' GC page ¤ Sun Tutorial on Objects ¤ Sun's tutorial ¤ survey article in PostScript format ¤ Tuning Garbage collection with the 1.3.1 Java Virtual Machine

home	Canadian Mind Products
	mindprod.com IP:[24.87.56.253]
	Your IP:[80.134.30.163]
	You are visitor number 3641.
	Please send errors, omissions and suggestions
	to improve this page to Roedy Green.
	You can get a fresh copy of this page from:	or possibly from your local J: drive mirror:
	http://mindprod.com/jgloss/garbagecollection.html	J:\mindprod\jgloss\garbagecollection.html