From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Date: Mon, 12 Aug 2019 19:49:43 +0300 Message-ID: <83wofis508.fsf@gnu.org> References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="130324"; mail-complaints-to="usenet@blaine.gmane.org" Cc: mattiase@acm.org, 37006@debbugs.gnu.org To: Joseph Mingrone , Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 12 18:51:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hxDXM-000Xml-Pp for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Aug 2019 18:51:12 +0200 Original-Received: from localhost ([::1]:47294 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxDXL-0007Gb-OB for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Aug 2019 12:51:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56982) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxDXE-0007Ey-UE for bug-gnu-emacs@gnu.org; Mon, 12 Aug 2019 12:51:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hxDXC-0003iw-VH for bug-gnu-emacs@gnu.org; Mon, 12 Aug 2019 12:51:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38526) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hxDXC-0003ie-Gy for bug-gnu-emacs@gnu.org; Mon, 12 Aug 2019 12:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hxDXC-0004GH-Cx for bug-gnu-emacs@gnu.org; Mon, 12 Aug 2019 12:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Aug 2019 16:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156562860816311 (code B ref 37006); Mon, 12 Aug 2019 16:51:02 +0000 Original-Received: (at 37006) by debbugs.gnu.org; 12 Aug 2019 16:50:08 +0000 Original-Received: from localhost ([127.0.0.1]:47347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxDWK-0004F1-Cr for submit@debbugs.gnu.org; Mon, 12 Aug 2019 12:50:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44493) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxDWF-0004EO-M4 for 37006@debbugs.gnu.org; Mon, 12 Aug 2019 12:50:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxDW9-0003FP-KN; Mon, 12 Aug 2019 12:49:57 -0400 Original-Received: from [176.228.60.248] (port=1033 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxDW9-0003I2-1J; Mon, 12 Aug 2019 12:49:57 -0400 In-reply-to: <868srysb9x.fsf@phe.ftfl.ca> (message from Joseph Mingrone on Mon, 12 Aug 2019 11:34:18 -0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:164922 Archived-At: > From: Joseph Mingrone > Cc: mattiase@acm.org, eggert@cs.ucla.edu, 37006@debbugs.gnu.org > Date: Mon, 12 Aug 2019 11:34:18 -0300 > > The fix did not initially work for me. I tested a bit more. With > > 1. emacs -Q > 2. (setq garbage-collection-messages t) > 3. page through xdisp.c > > I saw lots of garbage collection messages. But, with my init.el there > were no such messages. My init.el looked like this. > > ---------------------------------------------------- > (setq gc-cons-threshold most-positive-fixnum) > > ;; contents of init.el here > > (setq gc-cons-threshold 800000) ;; default value > ---------------------------------------------------- > > When I removed the surrounding setqs, garbage collection message were > shown again when paging through xdisp.c. > > I assume that temporarily setting `gc-cons-threshold' to a large number > to temporarily prevent garbage collection, then setting it back to a > reasonable value should be acceptable. Yes, of course. There's a separate bug in the recent GC-related changes. Thanks for pointing this out. Paul, the current method of updating consing_until_gc only in garbage_collect_1 isn't workable, because it doesn't support the (very popular nowadays) paradigm of temporarily setting gc-cons-threshold very high: doing so avoids calling garbage_collect_1, and thus the change of the threshold back to a lower value is never seen. We must have something in maybe_gc to notice the change and recompute the threshold. We must also notice the memory-full condition there. We need to fix this ASAP, please. I also don't think I understand the details of the threshold calculations: if (!NILP (Vmemory_full)) consing_until_gc = memory_full_cons_threshold; else { intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD, gc_cons_threshold >> 3), OBJECT_CT_MAX); if (FLOATP (Vgc_cons_percentage)) { double tot = (XFLOAT_DATA (Vgc_cons_percentage) * total_bytes_of_live_objects ()); if (threshold < tot) { if (tot < OBJECT_CT_MAX) threshold = tot; else threshold = OBJECT_CT_MAX; } } consing_until_gc = threshold; } First, gc_cons_threshold is an EMACS_INT, so putting its value into intptr_t is wrong in 32-bit builds --with-wide-int, right? For the same reason, using intptr_t for OBJECT_CT_MAX is wrong in such a build. And second, why does the code divide gc_cons_threshold by 8? If the value of gc_cons_threshold is most-positive-fixnum, that is wrong, I think. Did you mean to divide GC_DEFAULT_THRESHOLD instead?