[Gc] Optimal memory management

Hans Boehm Hans.Boehm@hp.com
Tue, 26 Aug 2003 19:50:01 -0700 (PDT)

On Mon, 25 Aug 2003, Tim Harrington wrote:

> I have a somewhat unique situation with the collector and could use some
> guidance.  In my situation, the gc code allocates memory from a
> particular heap unless it's a fairly large allocation (>64K).  In that
> case, the memory is returned from a heap much "further away" in memory.
> For instance, small allocations come from the 0x004nnnn range but large
> allocation come from the 0x6nnnnnnn range.
I'm a little surprised by that behavior, though it's almost certainly
possible.  Or are you saying you are allocating the large objects through
a different mechanism?
> It appears that the collector keeps a high and low water mark of
> addresses it allocates.  Is it true that it scans ALL memory addresses
> between those marks?  I'd hate for it to run all the addresses that are
> not necessarily valid.
It doesn't.  It keeps approximate bounds on the heap for two reasons:

1) It speeds up the pointer recognition test.
2) It's necessary for the blacklisting code, since it needs to recognize
integers that "point" to someplace near the heap.

> I've looked at GC_add_roots() to manage the
> memory externally, but there's no easy way to remove the root once it's
> added so there's not much I can do when the memory is deallocated.
That shouldn't be necessary, unless I'm misunderstanding something.
> Maybe I'm just confused and the collector actually knows about the holes
> between allocations.  It's been a while since I ported it so my
> knowledge of the innards is somewhat fuzzy.
Assuming all allocation is done through the collector, you should be fine.