bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006

[Dmitry Antipov]

On 12/02/2013 09:52 PM, Eli Zaretskii wrote:

> Thanks.  But I think I didn't make myself clear: the issue is not just
> to see ANY font-spec objects being marked.  The issue is with those
> font-spec objects that are recorded in the font caches that are
> compacted by compact_font_caches.  I don't see any code that makes
> sure some Lisp object references those caches.  Without that, they
> cannot be possibly marked, and will be GC'ed, right?

Yes, but this is somewhat similar to markers.  All markers are chained
via 'next' pointers into per-buffer lists, but there is no guarantee that
_each_ marker is referenced in some other way.  Instead, the marker _may_
be referenced from some other object.  If this is so, the marker is live.
Otherwise it's dead.

>> But the most of font-spec and font-entity objects are referenced via
>> staticpro'ed globals Vfontset_table and ft_face_cache.
>
> Those staticpro'ed objects might just be the reason why you don't see
> the problem.  Your build uses the ftfont driver, doesn't it?  Because
> ftfont.c has this implementation of the get_cache method:
>
>    static Lisp_Object
>    ftfont_get_cache (struct frame *f)
>    {
>      return freetype_font_cache;
>    }
>
> and freetype_font_cache is a staticpro'ed variable.  By contrast,
> w32font.c does this:
>
>    Lisp_Object
>    w32font_get_cache (struct frame *f)
>    {
>      struct w32_display_info *dpyinfo = FRAME_DISPLAY_INFO (f);
>
>      return (dpyinfo->name_list_element);
>    }
>
> and dpyinfo->name_list_element is what compact_font_caches examines.

But Vfontset_table should present on MS-Windows too, isn't it?

> Anyway, I think we are mis-communicating again: the above Lisp code
> will cause the breakpoint to fire with i == size, i.e. we will remove
> the font-entities from the cache.  I wanted the opposite: to see at
> least 1 font-entity that is NOT removed.  So my breakpoint condition
> was "i != size", which means we will NOT drop the font-entity.  What I
> saw is that this condition is never true, which means we remove ALL of
> the font-entities from the cache.

I understand the problem, but (as of r115362) I'm able to hit the breakpoint
on the 'break' statement before 'if (i == size)' and found marked font-entity:

...
Breakpoint 1, compact_font_cache_entry (entry=...) at 
../../trunk/src/alloc.c:5327
5327                  break;
(gdb) bt 4
#0  compact_font_cache_entry (entry=...) at ../../trunk/src/alloc.c:5327
#1  0x00000000005ea772 in compact_font_caches () at ../../trunk/src/alloc.c:5357
#2  0x00000000005ead99 in Fgarbage_collect () at ../../trunk/src/alloc.c:5531
#3  0x00000000005635d8 in maybe_gc () at ../../trunk/src/lisp.h:4462
(More stack frames follow...)
(gdb) p i
$1 = 0
(gdb) p size
$2 = 4
(gdb) p XFONT_ENTITY (AREF (XCDR (obj), i))
$3 = (struct font_entity *) 0x12fd578
(gdb) p /x XFONT_ENTITY (AREF (XCDR (obj), i))->header.size & ARRAY_MARK_FLAG
$4 = 0x8000000000000000       ;;; non-zero ==> mark bit is set
...

Since this font-entity is marked, the whole cache entry is not removed.

I'll try to trace marking and find an object which references this font-entity.

Dmitry