From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.bugs Subject: bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006 Date: Tue, 03 Dec 2013 13:57:01 +0400 Message-ID: <529DAAED.9000504@yandex.ru> 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> <834n6r5edh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1386064696 6668 80.91.229.3 (3 Dec 2013 09:58:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2013 09:58:16 +0000 (UTC) Cc: sva-news@mygooglest.com, 15876@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 03 10:58:21 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 1VnmkG-0004lD-CV for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2013 10:58:20 +0100 Original-Received: from localhost ([::1]:41344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnmkG-0006ot-2c for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2013 04:58:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vnmk5-0006ns-N3 for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 04:58:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vnmjy-0004HM-OP for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 04:58:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vnmjy-0004HI-Ku for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 04:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vnmjy-0006fR-6H for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 04:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Dec 2013 09:58: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.138606463225564 (code B ref 15876); Tue, 03 Dec 2013 09:58:02 +0000 Original-Received: (at 15876) by debbugs.gnu.org; 3 Dec 2013 09:57:12 +0000 Original-Received: from localhost ([127.0.0.1]:55533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vnmj9-0006eF-N5 for submit@debbugs.gnu.org; Tue, 03 Dec 2013 04:57:12 -0500 Original-Received: from forward2h.mail.yandex.net ([84.201.187.147]:39164) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vnmj8-0006e3-6W for 15876@debbugs.gnu.org; Tue, 03 Dec 2013 04:57:11 -0500 Original-Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward2h.mail.yandex.net (Yandex) with ESMTP id 59C58701B6F; Tue, 3 Dec 2013 13:57:03 +0400 (MSK) Original-Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id C0022170147D; Tue, 3 Dec 2013 13:57:02 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id RZ3SE7pgD2-v2A4N4IN; Tue, 3 Dec 2013 13:57:02 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1386064622; bh=FKb2N5TzXdhNO1SBE2+cVXtzu7Cg/uVWuqa/WJHJZjk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lYHRKE8GP3N8RRQ0UFL/HTXV6mioepSw2IbhxCOSzKtG5R8n0oIuZcVqzFPK0tu72 Vj49rgRkh9m9LCk1siGaSEkLgAr/BB2nCPV5kOZoj/i7cBFHXK+0qp9kp1daPB8e+t QrYddRhgxeYORN3jL1VYPpeWXfSZgndjm7sFjHQI= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: <834n6r5edh.fsf@gnu.org> 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:81299 Archived-At: 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