Karl Fogel writes:
> "Glenn A. Thompson" <gthompson@cdr.net> writes:
> > What change made it 1/3 the size it used to be? Was it just the
> > trail.c changes for scratchpool? Or was there something else?
>
> No, I don't think so. Revision 3589 added the scratchpool, but didn't
> change anyone to actually use it yet. The change that brought the
> memory usage down was probably revision 3469.
>
> Note how Ben says in the issue that most the memory is not showing up
> in the pool statistics at all. His 40MB figure is coming from 'top'!
> As far as the pool debug output goes, pool usage hovers at about 3MB.
> That's the main clue that it might be a problem with our Berkeley DB
> usage...
I feel kind of funny pointing this out since I'm the person behind this
issue, but 'top' isn't a reliable means of determining how much memory you
have allocated at the moment.
Every major Un*x OS I know of (including FreeBSD) uses a caching mechanism
behind (m|c|re)alloc so that memory you free() is rarely actually returned
to the OS (regardless of what the FreeBSD malloc() manual page states).
This effect is easy to see. Write a short program that does the following:
1. Allocate on the heap a huge array of elements of size X.
A good choice for X is 16 bytes.
2. Wait for user input to continue.
3. Free the memory.
4. Wait for user input to continue.
5. Allocate on the heap a huge array of elements of size 2X or 3X.
6. Wait for user input to continue.
7. Free the memory.
8. Wait for user input to end the program.
Have 'top' running in another window. What you will see is that the first
batch of memory you allocate appears to still be in use after you free it
and at the end of the program you still seem to have everything allocated.
Most versions of (m|c|re)alloc have a list of variable sized chunks of
memory they keep allocated after a free() under the assumption you will
allocate a chunk about the same size again. These chunks usuallly vary by
16 or 32 bytes up to around 256 after which they no longer cache or pass
you off to mmap behind your back. Allocate a slightly different sized
chunk and you allocate more memory rather than using the cache of already
allocated memory.
So, perhaps we should make sure this isn't what we are seeing before we
bang our heads against the wall trying to track down our "leak". It might
not be there or may be even smaller than we imagine.
Michael
P.S. You can browse the libstdc++ source included with gcc for an example
of exactly how much caching your memory system may be doing behind
your back.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 6 20:33:39 2002