GNU bug report logs -
#43389
28.0.50; Emacs memory leaks
Previous Next
Full log
Message #704 received at 43389 <at> debbugs.gnu.org (full text, mbox):
Stefan, please help with this complex issue (or maybe several
issues). We have collected some evidence in this bug report, but I
don't yet see where is this going, or how to make any real progress
here.
One thing that I cannot explain is this:
> From: Trevor Bentley <trevor <at> trevorbentley.com>
> Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support,
> dj <at> redhat.com, michael_heerdegen <at> web.de
> Cc:
> Date: Tue, 08 Dec 2020 22:50:37 +0100
>
> I've been too busy to modify emacs to print garbage collects, but
> these still show really long (garbage-collect) calls, often
> exceeding 15 minutes.
Trevor reported several times that automatic GC is fast as usual, but
manual invocations of "M-x garbage-collect" take much longer, many
minutes. I don't understand how this could happen, because both
methods of invoking GC do exactly the same job.
I thought about possible ways of explaining the stark differences in
the time it takes to GC, and came up with these:
. The depth of the run-time (C-level) stack. If this is much deeper
in one of the cases, it could explain the longer time. But in that
case, I'd expect the automatic GC to take longer, because typically
the C stack is relatively shallow when Emacs is idle than when it
runs some Lisp. This contradicts Trevor's observations.
. Some difference in buffers and strings, which causes the manual GC
to relocate and compact a lot of them. But again: (a) why the
automatic GC never hits the same condition, and (b) I can explain
the reverse easier, i.e. that lots of temporary strings and buffers
exist while Lisp runs, but not when Emacs is idle.
Any other ideas? Any data Trevor could provide, e.g. by attaching a
debugger during these prolonged GC, and telling us something
interesting?
TIA
This bug report was last modified 4 years and 58 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.