So it seems from my trivial analysis that there are instances when
Ruby's GC doesn't recover recoverable memory.

My first attempt to fight this was to think that perhaps, when walking
the stack during GC -- "maybe it finds heap chunks that are actually
freed memory" -- turns out it does (and it is accounted for in the
code gc_mark ignores the request to mark it).  However--believe it or
not, if you scan the free list when this occurs, at times these
'freed' slots in the heap are not then found in the free list.  Is
that possible?  Well obviously it is, but is that reasonable?  I guess
I should expect that from scope objects?

Anyway, I had a few thoughts with regard to the ominous 'ruby doesn't
recover all available memory for recovery'

Questions:
when it walks the stack does it perhaps go over sections that are
'unused' of the stack, that contain old references to things?  Are
there varmaps perhaps in there that need to be cleaned, as you go out
of scope?  Or locals? Or parameters that should be cleared as you go
out of scope, perhaps?
Pointers to varmaps or scope objects that were passed as parameters,
maybe, that need to be set to 0?


It might be nice to optionally write a graphviz file of how memory is
'walked' so one could see where the leak is happening (if any--on the
stack or what not).

Anyway good luck to all.  Seems almost like it would be easier to just
write a reference counting GC than find this bug, should it be a bug
:)  I'd be willing to offer someone $100 US to build a reference
counting GC for 1.9 :)

-Roger