[Gc] Optimal memory management
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.