bear wrote:

> I've been bitten by this while using a genetic algorithm.  I had
> "random-looking" bit patterns (the genomes) filling almost 2Gbytes of
> memory space, and the Boehm collector was mistaking almost half of
> the words for possible pointers.  It eventually reached a tipping
> point where the values it couldn't free contained enough
> "pseudopointers" to prevent it from freeing anything else, and
> crashed.

That's misidentifying non-pointers as pointer, which is a performance
issue (which in worst case can cause out-of-memory problems).
There are various ways to tweak/tune Boehm GC to reduce that.
Clearly including 2G of non-pointer data in the conservatively
scanned heap is likely to lose!

Boehm GC can be used in a hybrid mode, using precise scanning for part
or all of the heap.  This is what GCJ does.

The problem Tom is referring to is (I assume) misidentifying a pointer
as a non-pointer.  That can happen if:
(a) You didn't tell the collector to scan the area containing the
pointer (most common problem).
(b) the pointer is "mangled", either through "clever" coding (such as
the xor-trick for double-linked lists) or an optimizing compiler
being to clever.  The former is a 'don't do that".  The latter is
very rare, but can conceivably happen if the compiler generates an
offsetted pointer while without leaving any reference to the actual
object start.  Boehm GC can be configured to also check "interior
pointers"; this reduces the problem, this hurts performance.

See http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html
especially the "Safety" section.

Tom Lord wrote:

 > On a hunch, you review some of
 > the functions that you think your program is exercising to an unusual
 > degree and, sure enough -- find a conservative GC bug.

What kind of "cerservative GC bug"?  Is this with the Boehm GC?  Are
these C functions, Scheme functions, or what?  Is it an optimizer bug?
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/