[gclist] memory leaks and the Boehm collector

[Hans Boehm]

On Jul 15,  3:56pm, cd_smith@ou.edu wrote:
> No real-life ones, although it's not that hard to produce sample cases
> where leaks like this happen, at least as of circa JDK 1.1.6.  One
> particular situation that I remember (became a relatively large thread on
> comp.lang.java.help about a year ago IIRC) involved building a linked list
> and stepping the head pointer forward... apparently, the original head was
> kept somewhere because GC would preserve the entire list.  Adding any sort
> of real processing to the program (besides just adding a list element and
> then head = head.next) eliminated the problem entirely, making it somewhat
> irrelevant in the real world.
>
I think we can call that the canonical example.  Variations of it have been
rediscovered by a number of people.  (The earliest is probably Wentworth's 1990
SP&E paper.)  In some sense, it's provably the only kind of example:  Any
unbounded leak from a single misidentified pointer must involve a growing chain
of objects ending at a live object.  (See
http://reality.sgi.com/boehm/bounds.html for most of the argument.)

This particular case is also easily avoidable in a language like Java:  Clear
the link field when you step the last pointer forward.  Although this is a
moderately ugly workaround, you should use it even without a conservative
collector.  Essentially the same phenomenon can cause all objects to be
promoted to the oldest generation in a generational collector.  (And unlike
manual deallocation, it's of course safe; errors cannot affect other data
structures.)

Hans



-- 
Hans-J. Boehm
boehm@sgi.com