[Spread-users] Memory leak? FD leak? Other?

[John Schultz]

David Shaw wrote:
> 
> This isn't true for all platforms.  With glibc (i.e. virtually all
> Linux systems), if you free a memory block, glibc may shrink your
> heap, giving memory back to the OS.  The OpenBSD libc does the same.
> It all depends on a number of factors and platform-specific things,
> and fragmentation can make this difficult, but glibc neatly hides all
> this from the application.  Some memory allocators even do things like
> mmap-ing /dev/zero and thus make it dead easy to release memory back
> to the system.
> 
Generic memory managers can try to release pages, but memory 
fragmentation usually makes this *very* difficult except when large 
block allocations are released.

> My point is that in general, it's not a good idea to try and outsmart
> the OS here.  When you want memory, malloc() it.  When you are done
> with it, free() it.  Let the memory allocator do its job.
> 
> It's okay to keep some memory around if you are concerned about malloc
> being too slow or other reasons, but then you really need to cap your
> personal memory pool at some sane value so that a one-time spike in
> memory usage doesn't result in your process permanently owning most of
> the memory on the system (and thus preventing other processes from
> doing something useful with it).
> 
I'm pretty sure this is what Spread does, but Jonathan can fill us in if 
I'm wrong.

-- 
John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200