GNU bug report logs - #21556
25.0.50; Memory leak in emacs -Q with lucid (font cache cleared prematurely)

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: handa <at> gnu.org (K. Handa), Dima Kogan <dima <at> secretsauce.net>
Cc: dmantipov <at> yandex.ru, 21556 <at> debbugs.gnu.org
Subject: Re: bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font)
Date: Sun, 27 Sep 2015 11:09:18 +0300

> From: handa <at> gnu.org (K. Handa)
> Cc: 21556 <at> debbugs.gnu.org, dmantipov <at> yandex.ru
> Date: Sun, 27 Sep 2015 16:56:47 +0900
> 
> When I wrote the original code long ago, font listing and opening
> was very slow on GNU/Linux system.  So I tried to cache the result
> of listing as far as possible, and also tried to reuse the once
> opened font object as far as possible.  The latter means that even
> if a font object once created becomes unnecessary (perhaps because a
> frame is deleted), it is not freed, because, once a user displayed a
> specific character, it is displayed again with a very high
> possibility.  So, when a font is closed?  It is closed by an
> explicit call of clear-font-fache.  As far as I remember (though
> vaguely), that was my original intention.

So maybe we should simply remove (or ifdef away) the code that
compacts the font caches.  If your assumption about reusing the font
is anywhere near the truth, compacting the font cache gives us more
trouble than it gains: we get slow redisplay in some cases and random
hard-to-debug bugs, while the gains are only visible in very rare use
cases such as the one described in the Oct 2013 discussion.

Previous Next

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