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: Tue, 03 Dec 2013 15:16:34 +0200 Message-ID: <83ob4y3wi5.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> <834n6r5edh.fsf@gnu.org> <529DAAED.9000504@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1386076632 18096 80.91.229.3 (3 Dec 2013 13:17:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2013 13:17:12 +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 Tue Dec 03 14:17:15 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 1Vnpql-0000ZX-FC for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2013 14:17:15 +0100 Original-Received: from localhost ([::1]:42372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vnpqk-0007Il-UB for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2013 08:17:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vnpqd-0007Ic-TT for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 08:17:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnpqY-0002Au-S7 for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 08:17:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnpqY-0002Ap-Ol for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 08:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VnpqX-0004eD-Jx for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 08:17: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: Tue, 03 Dec 2013 13:17:01 +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.138607661117808 (code B ref 15876); Tue, 03 Dec 2013 13:17:01 +0000 Original-Received: (at 15876) by debbugs.gnu.org; 3 Dec 2013 13:16:51 +0000 Original-Received: from localhost ([127.0.0.1]:55651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnpqM-0004d7-Ja for submit@debbugs.gnu.org; Tue, 03 Dec 2013 08:16:51 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:49013) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnpqK-0004cR-9r for 15876@debbugs.gnu.org; Tue, 03 Dec 2013 08:16:49 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MX800500FIDO100@a-mtaout20.012.net.il> for 15876@debbugs.gnu.org; Tue, 03 Dec 2013 15:16:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MX8005EPFJKMV10@a-mtaout20.012.net.il>; Tue, 03 Dec 2013 15:16:32 +0200 (IST) In-reply-to: <529DAAED.9000504@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:81307 Archived-At: > Date: Tue, 03 Dec 2013 13:57:01 +0400 > From: Dmitry Antipov > CC: sva-news@mygooglest.com, 15876@debbugs.gnu.org > > 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. OK, but the difference is that a buffer is a Lisp object that is examined by GC, and so its marker list is examined. Where's something similar for the font caches? > But Vfontset_table should present on MS-Windows too, isn't it? It is present, but how is it related to the issue at hand? > > 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. This never happened to me on Windows.