[gclist] Java Developer's Journal GC advice

[Boehm, Hans]

Whether or not it makes sense to clear pointers in objects that are about to be dropped unfortunately depends on the collector.  It sometimes makes sense for a conservative collector.  (See my POPL 2002 paper for details.  You really only want to do this to avoid unbounded backward paths in the data structure, i.e. in very rare cases.)  Similarly it may make sense for a generational collector, especially when you are dropping a very old object that refers to young objects.  In this case, too, it really only makes sense for pointers that are likely to reference large or growing data structures, i.e. very rarely.

I don't view clearing of pointers as equivalent to explicit freeing:  The former is type-safe, while the latter isn't.  I don't think you can avoid pointer clearing completely if you care about space usage:

for (...) {x = make_huge_tree();}

requires twice the space of

for (...) {x = make_huge_tree(); x = null;}

if you assume a naive compiler.  But it's clearly something you want to do only rarely.

I would recommend against explicit forcing of GCs, at least given the Java interface.  Hints are probably useful.  But before you insist on a GC, you need to make sure that enough allocation has happened to justify it.  Typically it's hard for any one part of the application to know that, though the GC itself does.  I think I've heard at least as many anecdotes about the performance dropping through the floor due to overly frequent collections than about really successful applications of this technique.  Typically pause time isn't everything.

Hans

> -----Original Message-----
> From: Ken Anderson [mailto:kanderson@bbn.com]
> Sent: Friday, September 05, 2003 3:34 PM
> To: Pekka P. Pirinen
> Cc: gclist@iecc.com; Jscheme Users
> Subject: Re: [gclist] Java Developer's Journal GC advice
> 
> 
> 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
>