From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.bugs Subject: Re: the ...-unload-hook convention doesn't work Date: Sat, 17 Jan 2004 00:21:57 +0000 Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <200401051824.i05IOpP07535@raven.dms.auburn.edu> <200401091708.i09H8YU13964@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1074299014 5712 80.91.224.253 (17 Jan 2004 00:23:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 17 Jan 2004 00:23:34 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 17 01:23:28 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AheFM-0005JJ-00 for ; Sat, 17 Jan 2004 01:23:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AheEY-0007eP-RA for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Jan 2004 19:22:38 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AheEV-0007d5-Qb for bug-gnu-emacs@gnu.org; Fri, 16 Jan 2004 19:22:35 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AheDz-0007Rs-8L for bug-gnu-emacs@gnu.org; Fri, 16 Jan 2004 19:22:34 -0500 Original-Received: from [148.79.80.39] (helo=albion.dl.ac.uk) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AheDy-0007RE-P1 for bug-gnu-emacs@gnu.org; Fri, 16 Jan 2004 19:22:02 -0500 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 1AheDu-0006TE-00; Sat, 17 Jan 2004 00:21:58 +0000 Original-To: Simon Josefsson User-Agent: Gnus/5.1005 (Gnus v5.10.5) Emacs/21.2 (gnu/linux) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:6599 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:6599 Simon Josefsson writes: > Which feature is this? gnus-nocem (though it's probably not be doing me much good anyway without reading usenet). > Any hints on finding leaking code, in general? In that case I guess it fails to purge a hash table, which I couldn't easily follow. > I have been using the following to print out large symbols: > > (mapatoms (lambda (sym) > (let ((len (ignore-errors (length (symbol-value sym))))) > (if (and len (> len 500) (not (= len 507904))) > (insert (format "%s: %s\n" sym len)))))) > > But it doesn't seem to work well. You need dependency info tracing all slots from obarrays to start with, and then you won't account for data kept live through C code, at least (e.g. text properties). > I have been getting complaints > about exhausting the memory from Emacs without that code generating > anything interesting. My machine has 1 GB RAM, and emacs is typically > around 100MB but can grow to 300MB or so when I do something major in > Gnus. The message is probably misleading in that case -- see all its uses in alloc.c (?). The limit on what a Lisp pointer can address is 128MB (or 256 -- I can't remember) on a 32-bit system. I added a comment to that effect somewhere. The actual data in strings, for instance, aren't necessarily in the same address space, but as far as I remember, probably contribute to that limit because they're malloced from the same region of (end of) the machine's address space (whereas mmapped space is at the other end, at least under Linux). See (probably) the same comment as above. It's made worse because pages allocated in the big bag don't get freed at least until they're completely emptied by GC -- see unused conses &c in the GC statistics. (A different sort of leak -- buffer space -- can occur on systems like Solaris which don't use the relocating allocator, and/or the mmap mechanism -- I forget. I don't remember whether the buffer space is in the Lisp pointer range in that case or not. I thought rms vetoed the solution, but it's still in the version of TODO I have). > Essentially: how do I find out what is taking up all memory in Emacs? > Perhaps a package that report these things would be handy. You can't, without serious work on the internals. Replacing the GC, and perhaps the object representation, per TODO could/would address all these issues to a greater or lesser extent. I assume there's a policy against that now since the old one is being tinkered with. Implementing the TODO item on `long long' would remove the addressing limitation at the expense of larger data, at least using GCC.