all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: handa@gnu.org (K. Handa)
To: Eli Zaretskii <eliz@gnu.org>
Cc: dmantipov@yandex.ru, 21556@debbugs.gnu.org
Subject: bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font)
Date: Sun, 27 Sep 2015 16:56:47 +0900	[thread overview]
Message-ID: <87zj082t34.fsf@gnu.org> (raw)
In-Reply-To: <83y4ftfbjw.fsf@gnu.org> (message from Eli Zaretskii on Sat, 26 Sep 2015 18:24:51 +0300)

In article <83y4ftfbjw.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > > I guess I still don't know if the fonts are supposed to be marked or
> > > not. They appear to never be marked. Do you know where that is supposed
> > > to happen?
> > > 
> > > Furthermore, the compaction code is incomplete, at least for xft. Xft
> > > refence-counts the fonts, so you must close all fonts you have opened.
> > > Emacs stores the fonts that have been opened in the cache, so if it ever
> > > drops any fonts from the cache, it must tell xft to close, or else
> > > things leak, as we're seeing. I haven't tried to do this yet, but I
> > > suspect that the fonts should be marked, otherwise we'd be closing the
> > > font that we have just opened.

As the font compaction code (and some other work related to clearing
font cache) is done by Dmitry, I included him in CC:.

> > Originally, font caches were not compacted at all until that
> > discussion in Oct 2013; they are still not compacted now on w32.  To
> > figure out how to compact those caches correctly, I think we need to
> > start with the basics, and understand well the "life cycle" of a font
> > in Emacs, including its font-cache entries: when and how a font is
> > opened and registered in the cache, when and how (and whether) it is
> > closed and removed from the cache, etc.  This stuff is notoriously
> > under-documented in Emacs, and we no longer have active maintainers on
> > board who are familiar with it.
> > 
> > So I'm afraid we are on our own wrt these issues.  (I'm CC'ing
> > Handa-san, who wrote most of the font-related code, in the hope that
> > he could chime in at some point and help us.)

I feel very guilty for those under-documented codes.  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.

---
K. Handa
handa@gnu.org





  parent reply	other threads:[~2015-09-27  7:56 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-25  0:05 bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font) Dima Kogan
2015-09-25  6:45 ` Eli Zaretskii
2015-09-25  6:57   ` Dima Kogan
2015-09-25  8:44     ` Eli Zaretskii
2015-09-25  8:13   ` Dima Kogan
2015-09-25  8:49     ` Eli Zaretskii
2015-09-25  9:10       ` Eli Zaretskii
2015-09-25  9:30         ` Dima Kogan
2015-09-25  9:45           ` Eli Zaretskii
2015-09-25 10:03           ` Eli Zaretskii
     [not found] ` <83y4ftfbjw.fsf@gnu.org>
2015-09-27  7:56   ` K. Handa [this message]
2015-09-27  8:09     ` Eli Zaretskii
2015-09-28  9:22       ` Dima Kogan
2015-09-28  9:58         ` Eli Zaretskii
2015-09-29  9:28           ` Dima Kogan
2015-09-30  7:00             ` Eli Zaretskii
2015-09-30 10:16             ` Dmitry Antipov
2015-10-01  9:42               ` Dima Kogan
2015-10-01 13:27                 ` Dmitry Antipov
2015-10-01 18:50                   ` Dima Kogan
2015-10-02  5:04                     ` Dmitry Antipov
2015-10-02 18:56                       ` Dima Kogan
2015-10-29 22:51                       ` Dima Kogan
2015-10-30 14:20                         ` Eli Zaretskii
2015-10-30 19:17                           ` Dima Kogan
2015-10-30 20:38                             ` Eli Zaretskii
2015-10-30 20:50                               ` Dima Kogan
2015-11-09  2:55                             ` Dima Kogan
2015-11-09 16:38                               ` Eli Zaretskii
2019-11-17  6:34                               ` Lars Ingebrigtsen
2019-11-17 15:38                                 ` Eli Zaretskii
2019-11-17 21:27                                   ` Dima Kogan
2019-11-18  8:13                                     ` Lars Ingebrigtsen
2015-09-29 10:05       ` K. Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zj082t34.fsf@gnu.org \
    --to=handa@gnu.org \
    --cc=21556@debbugs.gnu.org \
    --cc=dmantipov@yandex.ru \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.