Ar an naoú lá déag de mí na Nollaig, scríobh Nix:
> I know, I'm saying the memory usage *reported by XEmacs*
seems
> reasonable. The bloat is not accounted for by objects we count, not
> even as a proportion, right?
Indeed not: `object-memory-usage-stats' reports sane values. The problem
is the actual amount of memory allocated (which is all, or nearly all,
traversed by the garbage collector: RSS goes up just as fast as VSZ.)
... hm. I just remembered Ulrich Drepper and Wolfram Gloger mentioning
(I think on libc-alpha a while back but it may have been in some paper
somewhere) that the glibc malloc hooks are pretty much completely broken
and don't work properly, especially in glibc 2.4+: as far as I can tell
we don't rely on those hooks except when terminating (to a very limited
degree) and as a debugging hack with no effect on memory-allocation
semantics, right?
(if so, damn, I'll have to actually do some *work* to diagnose this
rather than leaping directly to the solution by magic. :) )
The comp.unix.programmer FAQ approach to generating a stack trace and
wrapping malloc() with something that calls that would probably give an
exact idea of what’s calling what, irrespective of the malloc
implementation. Dog-slow, though.
Tangentally, has anyone got experience running XEmacs under valgrind? One
would need to do the temacs -batch -l ../lisp/loadup.el run-temacs thing, I
imagine, but it might help. (Am on NetBSD for my dev machine, which doesn’t
support it, unhappily.)
--
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta