Understanding Garbage Collection (p2/2)
In the first part, the very basic topics of garbage collection were presented. In this second article, I’ll be centered on garbage collection specifically for Java platform.
It’s all about references
As it was described in first part, just memory occupied for objects that have no references can be recycled.
There are two reference categories:
Strong references
Weak references
A Strong reference is one that references to a reachable object. On the other hand, a weak reference is a reference that doesn not ensure referenced object to be collected by GC. Any object refenced only for weak references is considered unreachable.
Java API defines the following weak reference model: http://download.oracle.com/javase/1.3/docs/api/java/lang/ref/package-summary.html
So, in Java there are three types of weak references:
Soft references
Weak references
Phantom references
The main difference between this types of weak reference is the way that JVM GC will act with them. So, if we have a soft reference, JVM can decide to collect, or not, that reference. In this case, JVM is plenty of heap memory, then, stopping application to collect its garbage maybe its not required.
On the other hand, weak references will be removed as soon as GC find one.
Finally, phantom references gives you the chance to recycle memory before the space is reclaimed.
Analyzing a garbage collector
There are several criterias that should be analyzed in order to evaluate a garbage collector:
Usage of CPU
Ways to predict pauses
Memory requirements (and interaction with additional memory systems
such as cache and virtual memory)Locality impact
There are other items to consider, but probably the listed above are the more relevant.
As you can imagine, GC is a HUGE topic. I hope that my two articles have excited the reader to continue investigating about it.
If that its your case, this is a rock solid first step: http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#1.1.Introduction%7Coutline
Written by Juan Carlos Cancela
Related protips
2 Responses
Garbage collection is great. But it would be great if we had the ability to arbitrarily "free" a given object and it's children, a-la-c/c++. As always the burden of avoiding run time errors is the responsibility of the developer. And frankly, I've done the math many times. The byte weight of recursive destroy code for complex data objects, is much greater than the null-pointer checking code required to account for an un-anticipated free operation.
From a perfomance perspective, having the option to manually admin memory would be an advantage. But it is more complex indeed. On the other hand, main advantage of gc's is the fact that hides the memory management complexity. In most of the cases i tend to think that memory management wouldnt be needed to get a proper performance. In most of the cases, but not any case :)
Have a fresh tip? Share with Coderwall community!
