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:04:13 +0300 Message-ID: <83ftm5ro8i.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> <83h86lrs8p.fsf@gnu.org> <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="216036"; mail-complaints-to="usenet@blaine.gmane.org" Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 13 19:05:10 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 1hxaEQ-000u44-2e for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Aug 2019 19:05:10 +0200 Original-Received: from localhost ([::1]:54452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxaEP-0001xv-3K for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Aug 2019 13:05:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33983) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxaEJ-0001ta-9J for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:05:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hxaEI-0003dg-8D for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:05:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39783) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hxaEI-0003dT-5L for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hxaEH-0002JE-TI for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2019 13:05: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:05: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.15657158748798 (code B ref 37006); Tue, 13 Aug 2019 17:05:01 +0000 Original-Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:04:34 +0000 Original-Received: from localhost ([127.0.0.1]:48604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxaDp-0002Hp-If for submit@debbugs.gnu.org; Tue, 13 Aug 2019 13:04:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxaDn-0002HP-T4 for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 13:04:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxaDi-0002mt-7s; Tue, 13 Aug 2019 13:04:26 -0400 Original-Received: from [176.228.60.248] (port=2871 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxaDh-0007Yl-L0; Tue, 13 Aug 2019 13:04:26 -0400 In-reply-to: <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Tue, 13 Aug 2019 18:48:05 +0200) 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:164940 Archived-At: > From: Mattias Engdegård > Date: Tue, 13 Aug 2019 18:48:05 +0200 > Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org > > > Yes, but the full calculation of the threshold is more complicated > > than that. For starters, how do you handle gc_cons_threshold values > > that are smaller than GC_DEFAULT_THRESHOLD / 10 under your proposal? > > There are use cases where the value was below that before and is above > > now, or the other way around, or was below and stays below. > > If a change to gc_cons_threshold has us end up in garbage_collect too soon, we can just adjust the bias and consing_until_gc and continue; the cost for doing so is small and amortised. Conversely, if the user raises gc_cons_threshold beyond the limit (OBJECT_CT_MAX), the intention is clearly to inhibit GC anyway. > > > And that's even before we consider other complications: when > > memory-full is non-nil, we should use a different threshold; and what > > about user changes to gc-cons-percentage? > > The check for memory-full was already eliminated from maybe_gc by changing consing_until_gc when that condition occurs, which seems reasonable enough. Regarding changes gc-cons-percentage, the effect will just be delayed to next GC --- is this really harmful? IOW, you think that whatever this changes in user-facing behavior is unimportant, and we shouldn't be bothered about it. I happen to disagree. > I could be wrong about all this; I'm a bit confused by the threshold computation, too. However, Paul's consolidation of conditions in the hot and inlined maybe_gc makes eminently sense to me. I cannot say the same thing myself, sorry. Making a frequent operation faster definitely makes sense, even if the speedup is minor. But doing that and as result breaking use cases that worked for years, or even just changing their effects in a tangible manner? what's our excuse for that?