GNU bug report logs - #43389
28.0.50; Emacs memory leaks

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Mon, 14 Sep 2020 00:44:01 UTC

Severity: normal

Merged with 43395, 43876, 44666

Found in version 28.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


Message #746 received at 43389 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com,
 carlos <at> redhat.com, trevor <at> trevorbentley.com, michael_heerdegen <at> web.de
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Sat, 12 Dec 2020 14:46:20 -0500
> Sure.  But isn't that the same as what I said, just from another POV?
> "A lot of objects to sweep" means there are many objects that aren't
> live and need to have their memory freed.
>
> Since GC wasn't run for many hours, having a lot of garbage to collect
> is expected, right?

Could be, but for tens of minutes?

AFAIK gc_sweep shouldn't cause too much thrashing either (the sweep is
a mostly sequential scan of memory, so even if the total heap is larger
than your total RAM, it should be ~O(total heap size / bandwidth from
swap partition)), so I can't imagine how we could spend tens of minutes
doing gc_sweep (or maybe the time is spend in gc_sweep but doing
something else than the sweep itself, e.g. handling weak pointers, or
removing dead markers from marker lists, ... still seems hard to
imagine spending tens of minutes, tho).


        Stefan





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.