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: Wed, 14 Aug 2019 18:37:44 -0700 Organization: UCLA Computer Science Department Message-ID: <18886155-d96b-ae07-1df2-1b1d58a8bbb2@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> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> <83ef1prly5.fsf@gnu.org> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> <83v9uzrasm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="184385"; 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: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 15 03:38:25 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 1hy4ie-000lre-AJ for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Aug 2019 03:38:24 +0200 Original-Received: from localhost ([::1]:37100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hy4id-0008C3-3J for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Aug 2019 21:38:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42619) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hy4iK-0007zx-1G for bug-gnu-emacs@gnu.org; Wed, 14 Aug 2019 21:38:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hy4iI-0001nf-N4 for bug-gnu-emacs@gnu.org; Wed, 14 Aug 2019 21:38:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41243) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hy4iI-0001nZ-K5 for bug-gnu-emacs@gnu.org; Wed, 14 Aug 2019 21:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hy4iI-0006zu-HQ for bug-gnu-emacs@gnu.org; Wed, 14 Aug 2019 21:38: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: Thu, 15 Aug 2019 01:38: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.156583307626865 (code B ref 37006); Thu, 15 Aug 2019 01:38:02 +0000 Original-Received: (at 37006) by debbugs.gnu.org; 15 Aug 2019 01:37:56 +0000 Original-Received: from localhost ([127.0.0.1]:50060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hy4i9-0006yn-MY for submit@debbugs.gnu.org; Wed, 14 Aug 2019 21:37:55 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hy4i7-0006yR-RR for 37006@debbugs.gnu.org; Wed, 14 Aug 2019 21:37:52 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F073D1616A8; Wed, 14 Aug 2019 18:37:45 -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 jqtD4uWJ5ryN; Wed, 14 Aug 2019 18:37:44 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 870361626EF; Wed, 14 Aug 2019 18:37:44 -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 bOtED6xe87ZS; Wed, 14 Aug 2019 18:37:44 -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 56E441616A8; Wed, 14 Aug 2019 18:37:44 -0700 (PDT) In-Reply-To: <83v9uzrasm.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:165010 Archived-At: Eli Zaretskii wrote: > 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). > 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. 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. > 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. > 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. >> 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.