From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Lost or corrupted `undo-tree' history Date: Fri, 10 Jan 2020 19:45:59 -0500 Message-ID: References: <1631cfa6-91e2-1fc9-85b8-fdb55a4aa765@Alexander.Shukaev.name> <835zhjag4g.fsf@gnu.org> <64a45342-251e-06b3-d836-6a0f19e3c114@Alexander.Shukaev.name> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="95349"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alexander Shukaev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 11 01:48:19 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.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 1iq4vz-000Ckn-0T for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Jan 2020 01:47:23 +0100 Original-Received: from localhost ([::1]:53236 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iq4vx-0006lh-8D for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Jan 2020 19:47:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43702) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iq4um-0005l1-3Z for emacs-devel@gnu.org; Fri, 10 Jan 2020 19:46:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iq4uk-0006WW-Pd for emacs-devel@gnu.org; Fri, 10 Jan 2020 19:46:07 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19516) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iq4uj-0006VZ-2S; Fri, 10 Jan 2020 19:46:05 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AF3B282C16; Fri, 10 Jan 2020 19:46:03 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2C62580B90; Fri, 10 Jan 2020 19:46:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1578703562; bh=Z1hhQT0Nv3P1VrCyWgzI5QpWP99Z/Lr6BZW3F/XLT0Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=e1py7YZthW8Ys51JiRgUgkWWA6RHV+3jbcgFkjV8LM6+4BT9eoye/c7gbCTnqxTuy vvaHcjUfFP4myL384DPWDCxdCMrHcWFvm32wVzrVHaPFw+fmoPveaHAVUt5lAnPOjv 0KxuWFJJ300w2ANpmMaHe2CeoVE7enRtTM5TTLbo1TV47/Fokcka5+3YCEgoBHBYOn DI55y/Y7AjwelsB1GJP5iRpWPTpcEO4HxFv2+HcfTQyF1/fEEyY6N/yRTLE+Qlj7dk vRCumsPiXbmJwUcQYSTddG/oUw5gnbv+nUfq1UUiZXYGBAqPX2q+qxp0UCturH7ty+ XhDn61JQPUXzg== Original-Received: from pastel (unknown [45.72.147.220]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2F2B4120623; Fri, 10 Jan 2020 19:46:01 -0500 (EST) In-Reply-To: <64a45342-251e-06b3-d836-6a0f19e3c114@Alexander.Shukaev.name> (Alexander Shukaev's message of "Fri, 10 Jan 2020 10:19:15 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:244177 Archived-At: > default value and garbage collecting starts immediately. However, the memory > consumption of Emacs does not fall back to 500MB, but rather goes down to > only e.g. 6GB, which afterwards are never ever reclaimed. As Eli mentioned, this is considered normal and not a leak. It only becomes a leak when the unused memory held cannot be reused for anything. > If I repeat the test, the memory consumption would immediately > continue to grow off 6GB further as if those 6GB are not reused and > are somehow stuck holding something that cannot be reclaimed anymore. This is more serious, OTOH. It might indeed be symptom of a leak. Of course, it can also come from a problem of fragmentation, or a number of other undesirables effects. Delaying GC (by raising `gc-cons-threshold`) tends to both increase the time it takes to a perform a GC cycle and also increase fragmentation. This is why Emacs's default setting errs on the side of GC'ing rather more often than less often. Stefan