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: Thu, 15 Aug 2019 17:17:43 +0300 Message-ID: <83o90qqzqw.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> <83v9uzrasm.fsf@gnu.org> <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="28918"; 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 Thu Aug 15 16:19:11 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 1hyGat-0007G0-5Z for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Aug 2019 16:19:11 +0200 Original-Received: from localhost ([::1]:42382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyGar-0003wz-RS for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Aug 2019 10:19:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53633) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyGZu-0002nO-9C for bug-gnu-emacs@gnu.org; Thu, 15 Aug 2019 10:18:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hyGZo-0001WX-6F for bug-gnu-emacs@gnu.org; Thu, 15 Aug 2019 10:18:10 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43276) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hyGZm-0001Vq-LG for bug-gnu-emacs@gnu.org; Thu, 15 Aug 2019 10:18:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hyGZm-0001N7-D9 for bug-gnu-emacs@gnu.org; Thu, 15 Aug 2019 10:18: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: Thu, 15 Aug 2019 14:18: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.15658786795262 (code B ref 37006); Thu, 15 Aug 2019 14:18:02 +0000 Original-Received: (at 37006) by debbugs.gnu.org; 15 Aug 2019 14:17:59 +0000 Original-Received: from localhost ([127.0.0.1]:52097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyGZi-0001Mo-Sg for submit@debbugs.gnu.org; Thu, 15 Aug 2019 10:17:59 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyGZh-0001Mb-PE for 37006@debbugs.gnu.org; Thu, 15 Aug 2019 10:17:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hyGZc-0001Qo-3t; Thu, 15 Aug 2019 10:17:52 -0400 Original-Received: from [176.228.60.248] (port=1039 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hyGZb-0001kD-Hw; Thu, 15 Aug 2019 10:17:51 -0400 In-reply-to: <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> (message from Paul Eggert on Wed, 14 Aug 2019 18:37:44 -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:165091 Archived-At: > Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org > From: Paul Eggert > Date: Wed, 14 Aug 2019 18:37:44 -0700 > > > However, I'd rather we don't invent new data types unless really > > necessary. > > I did that yesterday, in commit 2019-08-13T19:20:40Z!eggert@cs.ucla.edu > (b80559be212292d44ce14ca5e94505cab4d9a868). OK, but I still hope we will switch to EMACS_INT instead. > > gc-cons-threshold is a Lisp integer, a > > fixnum, so it cannot exceed EMACS_INT_MAX, I think. > > No, (setq gc-cons-threshold (1+ most-positive-fixnum)) works and does the right > thing. That makes gc-cons-threshold a bignum, right? I don't see why we should support such large values of the threshold, we never did before. most-positive-fixnum on 32-bit systems is large enough for every practical purpose. Also, supporting the full 32 bits (and 64 bits in 64-bit builds) will also allow contradictory situation whereby gc-cons-threshold is higher than what we say should be used to disable GC. > The variable's value can be any intmax_t value. This is useful for > quantities like GC object byte counts that might not fit into fixnums. Why do we need to talk about how many objects are there? GC threshold is not about counting objects, it's about deciding when to GC. > > Can we use for this purpose the existing trapped_write > > field of Lisp_Symbol that is the base for implementing Lisp watcher > > functions? > > Don't see why not. Are you working on that, or should someone else do it? > > 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. > > I don't think the scenario is worth worrying about doing a GC now rather than > later. But if we go the trapped_write route, this issue won't matter since the > GC will be done quickly. I don't think I understand how trapped writes could help in the case of memory-full, since that situation happens independently of setting the value of gc-cons-threshold. > >> Immediate-GC might cause GC thrashing, no? > > > > Not sure how, can you elaborate? > > When EMacs is low on memory, if we're not careful Emacs could GC every time > maybe_gc is called, which will be roughly equivalent to Emacs hanging and doing > nothing. Right, but that's not what I proposed. I proposed to trigger an immediate GC only the first time we detect memory-full. Thereafter, the threshold will be set to 1KB, which should prevent thrashing.