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

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: 21556@debbugs.gnu.org
> Date: Fri, 25 Sep 2015 02:30:45 -0700
> 
> 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.

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 can offer whatever
help I can extend, which is admittedly not too much.  If you have time
and motivation, I suggest to start from the end: i.e., figure out when
and how a font is closed and removed from Emacs.  If we are lucky,
perhaps the font cache compaction could be triggered by whatever
triggers a font's removal from Emacs.

Thanks.