Re: [PATCH] Fix compilation --with-debug-malloc && --with-error-checking=malloc; better dlmalloc overhead
On 29 Dec 2006, Stephen J. Turnbull spake thusly:
Nix writes:
> As an additional wrinkle, the Doug Lea malloc() has always had an
> overhead of at least 4 bytes per allocated chunk (8 bytes per chunk for
> machines with 8-bit pointers, more if this is a large request satisfied
> via mmap() rather than via arena allocation). For now, 4 bytes is more
> accurate than the previous figure of, um, 0. (What malloc() has no bytes
> of overhead?! How on earth would it track blocks?)
ISTR comments indicating that malloc overhead was handled in some sly
way. Am I misremembering?
There *is* code in alloc.c:malloced_storage_size() for SYSTEM_MALLOC
which does... interesting things to claimed_size(), but that's not quite
the same.
This is all tangled up with multiple-mallocs stuff anyway and thus is a
nest of (torpid) snakes...
I've always thought it absurd that you can't ask the system
for
information about a block if you hand it a pointer.
I concur, not least because free() *has* to track things like the size:
why can't it tell us what it is?
(btw, on a vaguely-related subject, the leak is suppressed: now I just
need to figure out why my crude suppression hack works and fix the thing
I've suppressed so it doesn't explode the arena. Memory usage still rises
but at ~10Mb/hr of heavy Gnus usage, which is much more acceptable given
that some of that could be accounted for by loading the odd elisp file
(maybe that happened and I didn't notice).
More definite info in a couple of hours unless something knocks me
offline: always possible when you're at the wrong end of a bad phone
line in the savage Yorkshire wilds...)
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches