From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Date: Tue, 13 Aug 2019 10:21:51 -0700 Organization: UCLA Computer Science Department Message-ID: <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> 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> <83wofis508.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3A5BBA64323C417A2FD237A2" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="19640"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: mattiase@acm.org, 37006@debbugs.gnu.org To: Eli Zaretskii , Joseph Mingrone Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 13 19:22:15 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 1hxaUw-0004ta-V1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Aug 2019 19:22:15 +0200 Original-Received: from localhost ([::1]:54532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxaUq-0007gk-DV for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Aug 2019 13:22:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35999) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxaUm-0007gS-2k for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:22:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hxaUk-0004ns-Ub for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:22:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39788) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hxaUk-0004ni-Qi for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hxaUk-0002nc-Kg for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2019 17:22: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.156571692110756 (code B ref 37006); Tue, 13 Aug 2019 17:22:02 +0000 Original-Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:22:01 +0000 Original-Received: from localhost ([127.0.0.1]:48609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxaUj-0002nN-6W for submit@debbugs.gnu.org; Tue, 13 Aug 2019 13:22:01 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxaUg-0002n6-IN for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 13:21:59 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C5CD1162729; Tue, 13 Aug 2019 10:21:52 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id tEzleCR-qOCF; Tue, 13 Aug 2019 10:21:51 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DF3E116272B; Tue, 13 Aug 2019 10:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mDfK3R24W3tt; Tue, 13 Aug 2019 10:21:51 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 8D7FF162729; Tue, 13 Aug 2019 10:21:51 -0700 (PDT) In-Reply-To: <83wofis508.fsf@gnu.org> Content-Language: en-US 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:164941 Archived-At: This is a multi-part message in MIME format. --------------3A5BBA64323C417A2FD237A2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Eli Zaretskii wrote: > We must > have something in maybe_gc to notice the change and recompute the > threshold. I don't see why the threshold needs to be recomputed on each maybe_gc call. I suppose we could add a new builtin variable type, so that the threshold could be recomputed whenever GC-related builtin variables are changed; that should do the trick without slowing down maybe_gc. But is it that important to recalculate the GC threshold immediately? Variables like gc-cons-threshold aren't intended for fine-grained control over exactly when the GC is called; they're merely advice. > We must also notice the memory-full condition there. memory_full already does that, no? It sets consing_until_gc. Or are you thinking of some other memory-full condition? > 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? That's not a problem, since the above code does min (..., OBJECT_CT_MAX) on the result before storing it into intptr_t. > using intptr_t for OBJECT_CT_MAX is wrong in such a build. I don't see why it's wrong. The idea is to count the total number of object bytes in use. This cannot exceed the number of bytes addressable by pointers regardless of the width of EMACS_INT, so intptr_t is appropriate for such counts. > 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? Right you are; that's a typo. Thanks. I fixed that in master in the attached patch. --------------3A5BBA64323C417A2FD237A2 Content-Type: text/x-patch; name="0001-Fix-GC-threshold-typo.patch" Content-Disposition: attachment; filename="0001-Fix-GC-threshold-typo.patch" Content-Transfer-Encoding: quoted-printable >From 1e5bda273a67f960fb834007f4653a630cd67ce9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 13 Aug 2019 10:03:41 -0700 Subject: [PATCH] Fix GC threshold typo MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Problem reported by Eli Zaretskii (Bug#37006#25). * src/alloc.c (garbage_collect_1): Fix typo in threshold calc. Go back to dividing by 10 since the numerator=E2=80=99s a constant now. Problem introduced in 2019-07-21T02:40:03Z!eggert@cs.ucla.edu. --- src/alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index 39833f8dec..c7419e2fa5 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -5932,8 +5932,8 @@ garbage_collect_1 (struct gcstat *gcst) consing_until_gc =3D memory_full_cons_threshold; else { - intptr_t threshold =3D min (max (GC_DEFAULT_THRESHOLD, - gc_cons_threshold >> 3), + intptr_t threshold =3D min (max (GC_DEFAULT_THRESHOLD / 10, + gc_cons_threshold), OBJECT_CT_MAX); if (FLOATP (Vgc_cons_percentage)) { --=20 2.17.1 --------------3A5BBA64323C417A2FD237A2--