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.Types of Garbage Collection
~ Roedy (1948-02-04 age:70)
- 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.
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:
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.
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.
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 comp.lang.java.progrogrammer, 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.recommend book⇒Garbage Collection: Algorithms for Automatic Dynamic Memory Management | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
by | Richard Jones, Rafael D Lins | 978-0-471-94148-4 | hardcover | |||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
publisher | Wiley | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
published | 1996-09-17 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
Expensive, but fun. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder. |
This page is posted |
http://mindprod.com/jgloss/garbagecollection.html | |
Optional Replicator mirror
|
J:\mindprod\jgloss\garbagecollection.html | |
Please read the feedback from other visitors,
or send your own feedback about the site. Contact Roedy. Please feel free to link to this page without explicit permission. | ||
Canadian
Mind
Products
IP:[65.110.21.43] Your face IP:[3.142.130.242] |
| |
Feedback |
You are visitor number | |