gc

gc

[Marius Nita]

hi,

i was wondering if anyone here has had any experience with the Boehm garbage
collector (libgc).

i noticed that while it does seem to collect memory correctly, the
reclaimed space is not shown by tools like ps and top. in a program, when you
call free(), system memory is automatically adjusted. (as shown by these
tools.) but when using the gc, say you allocate 10 megs, invalidate the
pointer to this memory and invoke the collector explicitly, these 10 megs are
reclaimed, but your process still shows up as using 10 megs... i don't know
how ps and top work, but if they rely on calls to free() to shrink usage
accordingly, that might explain it; since libgc implements its own allocators
on top of sbrk.

i don't think this is a huge issue, just wondering if anyone knows of a way
around it.

thanks
marius

Re: gc

[Glynn Clements]

Marius Nita wrote:

> i was wondering if anyone here has had any experience with the Boehm garbage
> collector (libgc).
> 
> i noticed that while it does seem to collect memory correctly, the
> reclaimed space is not shown by tools like ps and top. in a program, when you
> call free(), system memory is automatically adjusted. (as shown by these
> tools.)

Calling free() won't normally reduce the process' memory usage, which
is what ps/top/etc report.

The only situation where free() will actually return memory to the
system is if malloc() allocated a block of memory using anonymous
mmap() (rather than sbrk()), and the entire block is now unused. 
However, this situation seldom happens in real programs.

If you disable the use of anonymous mmap with mallopt(M_MMAP_MAX, 0),
malloc() will always use sbrk(), so free() would never reduce the
process size.

Aside: one consequence of using anonymous mmap() is that malloc() can
allocate memory which isn't included in the data segment resource
limit (setrlimit(RLIMIT_DATA, ...)).

-- 
Glynn Clements <glynn.clements@virgin.net>