From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#45200: Memory leaks: (garbage-collect) fails to reclaim memory Date: Sun, 13 Dec 2020 00:53:57 -0500 Message-ID: References: <83k0tmeq6f.fsf@gnu.org> <9f49e5542f303736d2e53ce3dc53c1374969e6b4.camel@yandex.ru> Reply-To: Eli Zaretskii Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26655"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45200@debbugs.gnu.org To: Konstantin Kharlamov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 13 06:55:10 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1koKLd-0006o3-AG for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Dec 2020 06:55:09 +0100 Original-Received: from localhost ([::1]:33504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koKLc-00014g-CE for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Dec 2020 00:55:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koKLV-00014Y-Ux for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2020 00:55:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35753) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koKLV-0002kp-N1 for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2020 00:55:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1koKLV-0004RE-Lv for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2020 00:55:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Dec 2020 05:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45200 X-GNU-PR-Package: emacs Original-Received: via spool by 45200-submit@debbugs.gnu.org id=B45200.160783884516960 (code B ref 45200); Sun, 13 Dec 2020 05:55:01 +0000 Original-Received: (at 45200) by debbugs.gnu.org; 13 Dec 2020 05:54:05 +0000 Original-Received: from localhost ([127.0.0.1]:47299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koKKb-0004PU-Bi for submit@debbugs.gnu.org; Sun, 13 Dec 2020 00:54:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koKKY-0004Ov-Se for 45200@debbugs.gnu.org; Sun, 13 Dec 2020 00:54:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59427) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koKKT-0002Hx-FX; Sun, 13 Dec 2020 00:53:57 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1koKKT-0007bp-7N; Sun, 13 Dec 2020 00:53:57 -0500 In-Reply-To: <9f49e5542f303736d2e53ce3dc53c1374969e6b4.camel@yandex.ru> (message from Konstantin Kharlamov on Sun, 13 Dec 2020 01:44:13 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:195932 Archived-At: > From: Konstantin Kharlamov > Cc: 45200@debbugs.gnu.org > Date: Sun, 13 Dec 2020 01:44:13 +0300 > > Alright, fair enough. I crafted up another testcase, it may be better. The following code first temporarily disables GC, then it prints "hello" 1000000 times, and finally it calls GC manually. > > I call `emacs -Q`, then measure PSS, then evaluate the code below, then again measure PSS. > > (let ((i 1000000)) > (setq gc-cons-threshold most-positive-fixnum) > (while (> i 0) > (print "hello") > (setq i (- i 1))) > (garbage-collect)) > > The loop takes 20-30 seconds for me, I think. PSS before is ≈41M, and PSS after is 266.3M. That is ≈200M of memory just vanished. That memory hasn't vanished, it is in your libc's malloc arena, available for future allocations. When and if it will be given back to the OS is up to the specifics of the malloc implementation. E.g., when I do the above on MS-Windows, where malloc is more eager to return memory to the OS, I end up with just 40 MB footprint, and if I then invoke GC manually, the memory goes down almost to the original value: 14 MB vs 12 MB after startup. There are many places on the Internet which explain why the memory footprint of a program doesn't go back to the original value even though the program frees all the heap memory it allocated. I suggest to read some of those explanations. > Regarding, whether it is stack size: > > λ grep VmStk /proc/283047/status > VmStk: 132 kB > > Apparently, it is not stack size. This is a misunderstanding. The space allocated for the stack doesn't need to grow. Values are pushed and popped there depending on the callstack depth, and Emacs regards anything on the stack that looks like a Lisp value or a pointer to a Lisp value as an indication that this Lisp value is in use, and shouldn't be GC'd.