[gclist] Java Developer's Journal GC advice

[Ken Anderson]

I agree with you that the advice in this article is suspect.

I think the nullify() method is misdirected.
If you have an object that you need to keep around that has a field full of an object you no longer need, you should set the field to null so the GC can GC the fields value.

Nulling all the fields of an object you are about to free can't help the GC, it will find what's free anyway.  It's just needless work.

k

At 05:24 PM 9/5/2003 +0100, Pekka P. Pirinen wrote:
>I bought Java Developer's Journal last week (Volume 8 Issue 7) to see
>what's going on in the Java world and because it had a GC cover story:
>"Avoid Bothersome Garbage Collection Pauses" (by some people at
>Lockheed-Martin: Lillian Andres, Chris Cargado, M. Valerie Underwood).
>Turns out they dole out some rather simplistic advice: incremental GC
>is dismissed with "timimg [...] may be inopportune", and they
>esssentially recommend manual "freeing" (by setting pointers to null)
>and explicit scheduling (System.gc) by the application.
>
>They summarize their advice in three steps:
>
>  1. Set all objects that are no longer in use to null and make sure
>     they're not left within some collection.  "Nullify" objects.
>  2. Force garbage collection to occur both:
>    * After some major memory-intense operation (e.g., scaling an
>      image) 
>    * At a periodic rate that provides the best performance for your
>      application 
>  3. Save long-lived data in a persistent data area if feasible or in a
>     pool of data and use the appropriate garbage collector algorithm.
>
>The last one is good advice.  So is forcing GCs after some
>memory-intense operations, but explicitly calling System.gc at
>intervals of X ms doesn't sound like an optimal way of tuning GC.  I
>don't have experience on this, but surely JVM GCs have tuning
>parameters that give better behaviour?
>
>Their example for nullifying shows a method that recursively sets all
>the object references.  This has bad caching behaviour and
>reintroduces half the problems of manual memory management, but they
>don't even mention that.
>-- 
>Pekka P. Pirinen
>A programming language is low level when its programs require attention to
>the irrelevant.  - Alan Perlis