From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006 Date: Mon, 02 Dec 2013 19:52:58 +0200 Message-ID: <834n6r5edh.fsf@gnu.org> References: <867gcdiqji.fsf@somewhere.org> <86fvr09z55.fsf@somewhere.org> <83fvr01du4.fsf@gnu.org> <8638n0nj9p.fsf@somewhere.org> <86bo1eaelv.fsf@somewhere.org> <86r4a2vqbu.fsf@somewhere.org> <867gbqdisp.fsf@somewhere.org> <83haas5y88.fsf@gnu.org> <529C64C5.2040509@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1386006860 32365 80.91.229.3 (2 Dec 2013 17:54:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Dec 2013 17:54:20 +0000 (UTC) Cc: sva-news@mygooglest.com, 15876@debbugs.gnu.org To: Dmitry Antipov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 02 18:54:22 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VnXhM-0000SE-Ca for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2013 18:54:20 +0100 Original-Received: from localhost ([::1]:38165 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnXhM-0006fk-0T for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2013 12:54:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnXhE-0006YA-Ox for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2013 12:54:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnXh5-0001Q2-6h for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2013 12:54:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnXh5-0001Ps-47 for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2013 12:54:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VnXh4-0006BI-Cc for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2013 12:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Dec 2013 17:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15876 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15876-submit@debbugs.gnu.org id=B15876.138600678823686 (code B ref 15876); Mon, 02 Dec 2013 17:54:02 +0000 Original-Received: (at 15876) by debbugs.gnu.org; 2 Dec 2013 17:53:08 +0000 Original-Received: from localhost ([127.0.0.1]:54978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnXgC-00069x-80 for submit@debbugs.gnu.org; Mon, 02 Dec 2013 12:53:08 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:57116) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnXgA-00069Q-3h for 15876@debbugs.gnu.org; Mon, 02 Dec 2013 12:53:07 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MX600K00XKHRG00@a-mtaout23.012.net.il> for 15876@debbugs.gnu.org; Mon, 02 Dec 2013 19:52:59 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MX600KQ7XOAOY50@a-mtaout23.012.net.il>; Mon, 02 Dec 2013 19:52:59 +0200 (IST) In-reply-to: <529C64C5.2040509@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:81265 Archived-At: > Date: Mon, 02 Dec 2013 14:45:25 +0400 > From: Dmitry Antipov > CC: 15876@debbugs.gnu.org > > On 12/01/2013 08:31 PM, Eli Zaretskii wrote: > > > Dmitry, can you please look into this? I'm not familiar enough with > > the font stuff, so I don't see how was the font-spec and its > > font-entities stored in the font cache supposed to be referenced from > > some other Lisp object, to make sure they are marked and not GC'ed. > > It should be easy - just use this: > > === modified file 'src/alloc.c' > --- src/alloc.c 2013-12-01 22:33:13 +0000 > +++ src/alloc.c 2013-12-02 09:32:55 +0000 > @@ -5731,7 +5731,18 @@ > eassert (!VECTOR_MARKED_P (ptr)); > VECTOR_MARK (ptr); /* Else mark it. */ > if (size & PSEUDOVECTOR_FLAG) > - size &= PSEUDOVECTOR_SIZE_MASK; > + { > + size &= PSEUDOVECTOR_SIZE_MASK; > + if (PSEUDOVECTOR_TYPEP (&ptr->header, PVEC_FONT)) > + { > + Lisp_Object tmp; > + XSETFONT (tmp, ptr); > + if (FONT_SPEC_P (tmp)) > + fprintf (stderr, "mark font-spec\n"); > + else if (FONT_ENTITY_P (tmp)) > + fprintf (stderr, "mark font-entity\n"); > + } > + } > > and set breakpoints to fprintf(). I tried this and see that font-spec > objects can be referenced from face caches: 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? > 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. (Note that xfont.c and xftfont.c also use a cache stored in dpyinfo->name_list_element, so this issue is not entirely Windows specific.) > > In any case, it seems like they are never marked on Windows, because > > if I set a breakpoint in the line marked below: > > > > /* If font-spec is not marked, most likely all font-entities > > are not marked too. But we must be sure that nothing is > > marked within OBJ before we really drop it. */ > > for (i = 0; i < size; i++) > > if (VECTOR_MARKED_P (XFONT_ENTITY (AREF (XCDR (obj), i)))) > > break; > > > > if (i == size) <<<<<<<<<<<<<<<<<<<<< > > drop = 1; > > } > > > > with a condition i != size, that breakpoint never breaks. > > The best way to hit this breakpoint is to run something like: > > (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)))) > > (This is X-specific; I believe there should be a similar MS-Windows method). What is X-specific here? If you mean x-list-fonts, then it exists on Windows and does the same. 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. > Subtle "triangle example" works just fine for me (with default font used by > GTK3 build and 'emacs -Q' at least). If the font cache is not cleared, you will not see any problem at all. > Also I'm curious how to reproduce this issue with X. In particular, how to > find a font so "heavy" that an attempt to load it creates a lot of Lisp data > (hundreds Kbytes, enough to reach gc_cons_threshold each time)? Well, you could lower gc_cons_threshold instead, couldn't you?