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: Wed, 14 Aug 2019 19:06:49 +0300 Message-ID: <83v9uzrasm.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> <83ef1prly5.fsf@gnu.org> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="241206"; 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 Wed Aug 14 18:08:12 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 1hxvop-0010c0-GS for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Aug 2019 18:08:11 +0200 Original-Received: from localhost ([::1]:33988 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hxvoo-0005pC-7A for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Aug 2019 12:08:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47846) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hxvoh-0005os-DN for bug-gnu-emacs@gnu.org; Wed, 14 Aug 2019 12:08:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hxvog-0005bF-8m for bug-gnu-emacs@gnu.org; Wed, 14 Aug 2019 12:08:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40780) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hxvog-0005b6-5Z for bug-gnu-emacs@gnu.org; Wed, 14 Aug 2019 12:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hxvof-0000L1-Up for bug-gnu-emacs@gnu.org; Wed, 14 Aug 2019 12:08: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: Wed, 14 Aug 2019 16:08: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.15657988281218 (code B ref 37006); Wed, 14 Aug 2019 16:08:01 +0000 Original-Received: (at 37006) by debbugs.gnu.org; 14 Aug 2019 16:07:08 +0000 Original-Received: from localhost ([127.0.0.1]:49601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxvno-0000Ja-1m for submit@debbugs.gnu.org; Wed, 14 Aug 2019 12:07:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxvnm-0000J7-7T for 37006@debbugs.gnu.org; Wed, 14 Aug 2019 12:07:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxvng-00052Z-HT; Wed, 14 Aug 2019 12:07:00 -0400 Original-Received: from [176.228.60.248] (port=3336 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxvnf-0005zm-TI; Wed, 14 Aug 2019 12:07:00 -0400 In-reply-to: <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> (message from Paul Eggert on Tue, 13 Aug 2019 12:32:24 -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:164980 Archived-At: > Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 13 Aug 2019 12:32:24 -0700 > > > OBJECT_CT_MAX should have the value EMACS_INT_MAX. > > Not if EMACS_INT_MAX < INTPTR_MAX, since object counts might overflow in that > case. However, I take your point that consing_until_gc can easily be made to > hold any fixnum value, so I installed the first attached patch. This is to some > extent overkill, since these variables should not be assumed to have this sort > of fine-grained control, but the change is tiny so should be fine. Thanks. However, I'd rather we don't invent new data types unless really necessary. I think we should simply use EMACS_INT (see below), but even if we end up using intptr_max, let's just use that directly, not introduce yet another type which we will have to look up every time we read this code. And likewise with the corresponding _MAX value. Using a non-standard data type makes the code harder to read. > Come to think of it, the limit should be INTMAX_MAX not EMACS_INT_MAX since > gc-cons-threshold could exceed EMACS_INT_MAX. Sorry, I don't think I follow. gc-cons-threshold is a Lisp integer, a fixnum, so it cannot exceed EMACS_INT_MAX, I think. > The idea would be to have a type that is like struct Lisp_Objfwd but with an > extra member, a function to be called whenever the variable is accessed. (Or > perhaps two extra members, a getter and a setter.) This could be useful for > other builtin vars, I suspect. Ah, okay. Can we use for this purpose the existing trapped_write field of Lisp_Symbol that is the base for implementing Lisp watcher functions? > > How else would you succeed in reacting to the change "soon enough"? > > There are other possibilities. We could have a timer, for example. I don't think timers are reliable enough, as they can be deferred for arbitrarily long time interval by some Lisp that takes a long time to finish. > >>> 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. > > Are you talking about the change in commit > 2019-07-20T02:40:03Z!eggert@cs.ucla.edu > (26de2d42d0460c5b193456950a568cb04a29dc00)? If so, I'm not quite following, as > the old code did not GC until consing_since_gc > memory_full_cons_threshold. I > expect that the idea was to not thrash doing GCs when memory is full. With the old code, whenever memory-full was non-nil, and consing_since_gc was more than the size of cons_block (about 1KB on my system), the very next maybe_gc call would actually trigger GC. With the new code, no matter how much consing happened before memory-full became non-nil, we still need to cons 1KB worth of objects before GC happens. This 1KB might be critical when we are out of memory. > Immediate-GC might cause GC thrashing, no? Not sure how, can you elaborate?