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: Tue, 13 Aug 2019 20:53:38 +0300 Message-ID: <83ef1prly5.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> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="159301"; mail-complaints-to="usenet@blaine.gmane.org" Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 13 19:55:16 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 1hxb0u-000fJo-5Q for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Aug 2019 19:55:16 +0200 Original-Received: from localhost ([::1]:54628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxb0t-0000HB-2S for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Aug 2019 13:55:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39546) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxb0h-0008Uo-1R for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:55:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hxb0f-0004dk-Vk for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:55:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39797) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hxb0f-0004da-Sg for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:55:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hxb0f-0003d9-Og for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2019 17:55:01 +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.156571884313811 (code B ref 37006); Tue, 13 Aug 2019 17:55:01 +0000 Original-Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:54:03 +0000 Original-Received: from localhost ([127.0.0.1]:48618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxazi-0003ah-Td for submit@debbugs.gnu.org; Tue, 13 Aug 2019 13:54:03 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55299) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxazg-0003a3-Lv for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 13:54:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxaza-000453-Ou; Tue, 13 Aug 2019 13:53:54 -0400 Original-Received: from [176.228.60.248] (port=1909 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxazZ-00027B-Q7; Tue, 13 Aug 2019 13:53:54 -0400 In-reply-to: <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> (message from Paul Eggert on Tue, 13 Aug 2019 10:21:51 -0700) 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:164943 Archived-At: > Cc: mattiase@acm.org, 37006@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 13 Aug 2019 10:21:51 -0700 > > > 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. I don't think I understand what this proposal means in practice. Can you elaborate, or show an example? > But is it that important to recalculate the GC threshold > immediately? How else would you succeed in reacting to the change "soon enough"? In the use case which triggered this bug report, setting gc-cons-threshold to a very large number disables GC for an extremely long time, and all that time the gc-cons-threshold changes made by the user are not acted upon. IOW, we could perhaps explain away a delay of seconds in acting upon the change, but we surely cannot explain away a delay of hours, let alone days. > Variables like gc-cons-threshold aren't intended for fine-grained > control over exactly when the GC is called; they're merely advice. Yes, but abrupt changes, like to most-positive-fixnum and then back to much smaller values, should produce at least approximately the expected behavior. In particular, changing from most-positive-fixnum to a value like 800000 should cause a GC "soon enough". If we don't test the value inside maybe_gc, what alternative mechanisms would you suggest to produce such an effect? > > We must also notice the memory-full condition there. > > memory_full already does that, no? It sets consing_until_gc. It sets it to a positive value, so no immediate GC will follow. The original code was setting the threshold to a very small value, so GC would happen immediately. I think the code in memory_full which sets consing_until_gc should be amended to (a) not raise consing_until_gc if the current value is already below memory_full_cons_threshold, and (b) probably even set it to the negative of sizeof (struct cons_block) so as to cause an immediate GC. > > 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. ??? But that effectively disallows/ignores values of gc-cons-threshold above LONG_MAX. Why would we make such a backward-incompatible change? When the user sets the value of that variable, the variable should keep its value, and we should be able to compare the threshold with the value of the user variable. If nothing else, arbitrarily throwing away high-order bits of the value is a sure path towards bugs due to confusion between these two value ranges. > > using intptr_t for OBJECT_CT_MAX is wrong in such a build. > > I don't see why it's wrong. Because OBJECT_CT_MAX should have the value EMACS_INT_MAX.