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: Thu, 15 Aug 2019 11:51:06 -0700 Organization: UCLA Computer Science Department Message-ID: <58673b86-d27f-c839-2eb6-bd0cbe7a70a5@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> <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> <83o90qqzqw.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="163802"; 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 20:54:28 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 1hyKtF-000gPL-N9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Aug 2019 20:54:25 +0200 Original-Received: from localhost ([::1]:46374 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyKtE-0000E7-AM for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Aug 2019 14:54:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40446) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyKqy-0006ng-R8 for bug-gnu-emacs@gnu.org; Thu, 15 Aug 2019 14:52:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hyKqw-0001Cq-9l for bug-gnu-emacs@gnu.org; Thu, 15 Aug 2019 14:52:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43616) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hyKqw-0001CH-6c for bug-gnu-emacs@gnu.org; Thu, 15 Aug 2019 14:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hyKqw-0004K1-3m for bug-gnu-emacs@gnu.org; Thu, 15 Aug 2019 14:52: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 18:52: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.156589507616563 (code B ref 37006); Thu, 15 Aug 2019 18:52:02 +0000 Original-Received: (at 37006) by debbugs.gnu.org; 15 Aug 2019 18:51:16 +0000 Original-Received: from localhost ([127.0.0.1]:52437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyKqC-0004J5-ED for submit@debbugs.gnu.org; Thu, 15 Aug 2019 14:51:16 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyKqA-0004Ip-0m for 37006@debbugs.gnu.org; Thu, 15 Aug 2019 14:51:14 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2CA01161379; Thu, 15 Aug 2019 11:51:08 -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 s8RJBkwSk8pI; Thu, 15 Aug 2019 11:51:07 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F419516272C; Thu, 15 Aug 2019 11:51:06 -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 DFNVW74VObhC; Thu, 15 Aug 2019 11:51:06 -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 C5E92161379; Thu, 15 Aug 2019 11:51:06 -0700 (PDT) In-Reply-To: <83o90qqzqw.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:165134 Archived-At: Eli Zaretskii wrote: > That makes gc-cons-threshold a bignum, right? If the user sets it to a bignum, yes. Ordinarily it's not. > most-positive-fixnum on 32-bit systems is large enough for > every practical purpose. It's not that hard for the number of consed bytes to exceed most-positive-fixnum on a 32-bit Emacs. Here's a simple test case to illustrate the phenomenon: (let* ((cons-size (car (cdr (car (garbage-collect))))) (long-length (1+ (/ most-positive-fixnum cons-size))) (l (make-list long-length nil))) (cons most-positive-fixnum (* cons-size (length l)))) This yielded (536870911 . 536870912) on the 32-bit Emacs that I just built. Of course a practical application would likely have a bunch of smaller lists, but the same basic idea applies. On such a platform, a user who wants to disable GC while fiddling with a bunch of large lists will need to set gc-cons-threshold to a bignum. > 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. Sorry, I'm not following. If setting gc-cons-threshold to a large value effectively disables GC, then setting gc-cons-threshold to a larger value should do the same thing. This is independent of any particular large value that we suggest in the manual. >> 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. The GC threshold is part of a related set of integers that count objects and bytes, for use in the returned value of garbage-collect among other things. It's convenient for it to be as least as wide as those other integers, so that calculations involving it do not overflow. >> Don't see why not. > > Are you working on that, or should someone else do it? I can add it to my list of things to do. To my mind, getting the timestamp API nailed down is more urgent, though, because fiddling with GC heuristics doesn't affect the API. > 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. Isn't it more complicated than that? Emacs can be low on memory, but can then get more and not be low on memory, and then be low on memory again later.