On 12/05/2013 09:36 PM, Eli Zaretskii wrote:

> Yes, I see the same on Windows.  However, I'm not sure we are looking
> at objects we should be looking at.  The ones your code traces are
> font objects.  By contrast, the entries in the font caches are cons
> cells like this:
>
>     (font-spec . [font-entity1 font-entity2 ...])
>
> IOW, I think we should be tracing font-specs and font-entities, not
> font objects.

IMO the real problem is that redisplay sometimes isn't clever enough about requesting
font for the particular character (0x25b7 in our case):

#0  font_make_entity () at ../../trunk/src/font.c:169
#1  0x00000000005a8a3f in xfont_list_pattern (display=display@entry=0x1379260,
     pattern=pattern@entry=0x7fffffff7730 "-adobe-courier-*-*-*--*-*-*-*-*-*-iso10646-1", registry=registry@entry=12260082,
     script=script@entry=12084946) at ../../trunk/src/xfont.c:403
#2  0x00000000005a9059 in xfont_list (f=<optimized out>, spec=12183525) at ../../trunk/src/xfont.c:515
#3  0x0000000000563193 in font_list_entities (f=f@entry=0x111fd58, spec=spec@entry=15986301) at ../../trunk/src/font.c:2735
#4  0x0000000000563b42 in font_find_for_lface (f=f@entry=0x111fd58, attrs=attrs@entry=0x16b9510, spec=<optimized out>,
     c=c@entry=9655) at ../../trunk/src/font.c:3206
#5  0x00000000005a9d44 in fontset_find_font (fontset=18338269, c=c@entry=9655, face=face@entry=0x16b9510, id=id@entry=-1,
     fallback=fallback@entry=false) at ../../trunk/src/fontset.c:681
#6  0x00000000005aa210 in fontset_font (fontset=fontset@entry=17988749, c=c@entry=9655, face=face@entry=0x16b9510, id=-1)
     at ../../trunk/src/fontset.c:754
#7  0x00000000005aacb2 in face_for_char (f=0x111fd58, face=face@entry=0x16b9510, c=9655, pos=<optimized out>, object=<optimized out>)
     at ../../trunk/src/fontset.c:978
#8  0x000000000043cb45 in get_next_display_element (it=it@entry=0x7fffffff97f0) at ../../trunk/src/xdisp.c:6997
#9  0x0000000000441bc3 in display_line (it=it@entry=0x7fffffff97f0) at ../../trunk/src/xdisp.c:19593
#10 0x000000000044506a in try_window (window=window@entry=17964077, pos=..., flags=flags@entry=1) at ../../trunk/src/xdisp.c:16505
#11 0x000000000045ab57 in redisplay_window (window=17964077, just_this_one_p=just_this_one_p@entry=false)
     at ../../trunk/src/xdisp.c:16022
#12 0x000000000045cbf3 in redisplay_window_0 (window=window@entry=17964077) at ../../trunk/src/xdisp.c:14023
#13 0x000000000054d216 in internal_condition_case_1 (bfun=bfun@entry=0x45cbc0 <redisplay_window_0>, arg=17964077,
     handlers=<optimized out>, hfun=hfun@entry=0x4290a0 <redisplay_window_error>) at ../../trunk/src/eval.c:1368
#14 0x000000000042d8ce in redisplay_windows (window=17964077) at ../../trunk/src/xdisp.c:14003
#15 0x000000000044a121 in redisplay_internal () at ../../trunk/src/xdisp.c:13602

Such a request produces a lot of font-entity objects, which are not needed (and becomes
reachable only via font cache) after the "best match" font is selected for the particular
character. Next, if font loading is too memory-intensive and gc_cons_threshold was hit, GC
clears font cache. Next cursor movement triggers redisplay, which in turn asks for the "best
match" for 0x25b7 again. If font cache is never cleared, this is acceptable because all possible
matches (represented as a vector of font-entities) are cached. But, if font cache is cleared,
font_list_entities calls to driver->list function, which creates a lot of font-entities again,
etc., etc.

Until we have somewhat smarter redisplay, possible solution is to clear font cache when it
becomes larger than some specified size rather than at each GC. Now I have the virtual machine
with Windows 7 installed, and this fix looks reasonable for me. Could you also please try it?

Dmitry