Re: Memory leaks in font objects

[Stefan Monnier]

> On my system, (length (x-list-fonts "*")) is 3007, and this function:

> (defun bloat-font ()
>   (interactive)
>   (let ((fonts (x-list-fonts "*")))
>     (while fonts
>       (condition-case nil (set-frame-font (car fonts)) (error nil))
>       (setq fonts (cdr fonts))
>       (redisplay))))

> causes Emacs (default GTK3 build) to grow up to ~360M RSS, mostly
> because a lot of font resources aren't freed when font objects are
> reclaimed.

That's unfortunate, indeed.

> Proper reclamation reduces RSS to ~150M.  This is the
> most giant memory leak I've ever seen.

Oddly enough, I'm not sure it's a leak.  Here's the result of my test:

             VM   RSS
   initial  204    24
   after 1  522   290
   after 2  539   305
   after 3  542   308
   after 4  542   308

So it's more like "once malloced, the memory can be reused by Emacs, but
not by another process because we never return it to the OS".
   
> --- src/font.h        2013-09-15 17:58:46 +0000
> +++ src/font.h        2013-10-24 05:47:08 +0000
> @@ -548,6 +548,10 @@
>    /* Close FONT on frame F.  */
>    void (*close) (struct frame *f, struct font *font);
 
> +  /* Finalize FONT when Lisp font-object is reclaimed.
> +     NOTE: this is called by GC.  */
> +  void (*finalize) (struct font *font);
> +
>    /* Optional (if FACE->extra is not used).
>       Prepare FACE for displaying characters by FONT on frame F by
>       storing some data in FACE->extra.  If successful, return 0.

What the difference between "close" and "finalize"?

I mean, your code does add what I'd call "finalization" to vectors, but
what it does to fonts wouldn't qualify as "finalization" to me, rather
it's just "freeing".  IOW to me, the vector's finalization code doesn't
*finalize* the font but *frees* the font.


        Stefan