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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Sat, 12 Dec 2020 21:51:15 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: trevor <at> trevorbentley.com,  carlos <at> redhat.com,  fweimer <at> redhat.com,
>   43389 <at> debbugs.gnu.org,  bugs <at> gnu.support,  dj <at> redhat.com,
>   michael_heerdegen <at> web.de
> 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?

If the system is paging, it could take that long, yes.

> 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).

Does gc_sweep involve touching all the memory we free?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.