bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font)

[K. Handa]

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