Long time no post as was busy with Guruji’s trip to Goa and a trip to The Art of Living International Center, Bangalore for Navrathri.
Anyways have been thinking about it for some time so thought to share:
From my experience what I have observed is that; different JVM’s have a different approach to Object Pooling (Object Pools is basically reusing or recycling the same object by storing them for future and using it in instead of disposing them and creating them whenever required.).
If we consider Java in general, Object pool’s are always discouraged (unless object creation is a heavy weight process for ex: JDBC Connection where object pools are beneficial). The reason being (search generational garbage collection on your favorite search engine) it add’s extra load on garbage collector because objects are slowly shifted to survivor or tenured generation from young because they are not de-allocated early and ultimately results in a Full GC (after a long time) which is absolutely a performance killer.
But where as in Android, Google recommends the opposite, it instead recommends Object Pools, which is quite evident also. (For example check the source code of Activity, Handler etc @ http://http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=core/java/android;hb=HEAD where Messages are taken from a Message Pool ). Now there can be many reasons for it. Memory Allocation and De-Allocation might be expensive. Another reason obvious is that Android (before 3.0) uses Mark and Sweep Algorithm for its Garbage Collection. What it basically does is that it timely checks the reference of each and every object; If an object is unreachable, then it is sent for collection or else nothing happens. It is one of the first and the oldest Garbage Collection algorithm.
The reason for different behavior towards Object Pooling is primarily the choice of algorithm used for Garbage Collection. Without object pooling there would be a lot of objects created and destroyed with time. Hence checking again and again for such object would obviously take longer time under Mark and Sweep. You can spend 100-200ms on one run and free 10bytes at the end which is bad (Check it on DDMS).
In Oracle’s HotSpot JVM, there are a lot of issues to deal with as rightly pointed out by Brian Goetz :
“In addition, object pooling has some serious downsides. Because the object pool is generally shared across all threads, allocation from the object pool can be a synchronization bottleneck. Pooling also forces you to manage deallocation explicitly, which reintroduces the risks of dangling pointers. Also, the pool size must be properly tuned to get the desired performance result. If it is too small, it will not prevent allocation; and if it is too large, resources that could get reclaimed will instead sit idle in the pool. By tying up memory that could be reclaimed, the use of object pools places additional pressure on the garbage collector. Writing an effective pool implementation is not simple.”
In Android, because each and every Object is timely checked, thus taking a long time. For which Object Pooling in itself is a better approach.
PS: For interested people: http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
PPS: Please comment or mail me, if you can find another reason for different approach.