[gclist] Java Developer's Journal GC advice

[Pekka P. Pirinen]

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