From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.bugs Subject: bug#45200: [PATCH] Force Glibc to free the memory freed Date: Wed, 03 Feb 2021 12:49:47 +0300 Message-ID: <09cc70f14e90f6b13b51b0536fae76e87dfe3f42.camel@yandex.ru> References: <83k0rz21dw.fsf@gnu.org> <331805c74fc5d3d412dd2065030b11fa3343710d.camel@yandex.ru> <8a91fc16f93298bca1281b43d6821ae3621376dc.camel@yandex.ru> <7ffacc5f-fc0e-a5f8-104d-2c0ae8e06953@gmx.at> <3f4f8b3034e9f52f48ec520f2732b1687bb24dbc.camel@yandex.ru> <31608795-6155-c7c9-7d94-6024adb0a3b9@gmx.at> 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="18410"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.38.3 Cc: carlos@redhat.com, fweimer@redhat.com, 45200@debbugs.gnu.org, dj@redhat.com To: martin rudalics , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 03 10:50:24 2021 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 1l7Eno-0004hP-8p for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 10:50:24 +0100 Original-Received: from localhost ([::1]:42244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7Enn-0002qh-Au for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 04:50:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60304) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7EnS-0002qb-MS for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 04:50:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53531) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l7EnS-0007nw-F2 for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 04:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l7EnS-0005fO-Dk for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 04:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Feb 2021 09:50:02 +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.161234580121772 (code B ref 45200); Wed, 03 Feb 2021 09:50:02 +0000 Original-Received: (at 45200) by debbugs.gnu.org; 3 Feb 2021 09:50:01 +0000 Original-Received: from localhost ([127.0.0.1]:36844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7EnQ-0005f3-IN for submit@debbugs.gnu.org; Wed, 03 Feb 2021 04:50:01 -0500 Original-Received: from forward106p.mail.yandex.net ([77.88.28.109]:39737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7EnN-0005el-LK for 45200@debbugs.gnu.org; Wed, 03 Feb 2021 04:49:59 -0500 Original-Received: from sas1-714ad325b0ec.qloud-c.yandex.net (sas1-714ad325b0ec.qloud-c.yandex.net [IPv6:2a02:6b8:c08:112c:0:640:714a:d325]) by forward106p.mail.yandex.net (Yandex) with ESMTP id 222CC1C80683; Wed, 3 Feb 2021 12:49:50 +0300 (MSK) Original-Received: from sas1-e00c2743cdb8.qloud-c.yandex.net (sas1-e00c2743cdb8.qloud-c.yandex.net [2a02:6b8:c14:3a22:0:640:e00c:2743]) by sas1-714ad325b0ec.qloud-c.yandex.net (mxback/Yandex) with ESMTP id rwhwOzud1B-nmHGVtaR; Wed, 03 Feb 2021 12:49:49 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1612345789; bh=MkuvrcRIpH+qDLQ8GqLsMJC8db38y2ETm738RKT3H5w=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=qD6Jvxp34IOcrsANx2LOxmo3KFh4v1xapP4zsmyV3tMSHXJUdnFYAAsWDcfuukJZj Cgbchd8K8j/UjfMgGpNfjpy4DKys4EpRV484a3PxTcW/TnNNjBPTBhbL8ZvB5cQ+RC X/dP/Lc6ly3Fw/fZMeAw4WrlTU7FTvp0L2BNVGRg= Authentication-Results: sas1-714ad325b0ec.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by sas1-e00c2743cdb8.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id GVfKEJa6IS-nmnOEAgf; Wed, 03 Feb 2021 12:49:48 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <31608795-6155-c7c9-7d94-6024adb0a3b9@gmx.at> 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:199185 Archived-At: On Wed, 2021-02-03 at 10:35 +0100, martin rudalics wrote: >  >> Does anyone really disable GC and get away with it? >  > >  > Sure. There's for example this post¹, which is probably where I got the > idea to only run GC on idle from. The question is highly upvoted, it has 4k > views, and the only positive answer basically says "it's okay as long as you > got memory" (well, I got memory), and notes that there's also a point in only > disabling GC during startup. Similar advice to only disable it during startup > has this pretty upvoted reddit post² >  > >  > Here's another example³, except in this case the author only disables GC > while they're inside minibuffer, and enables it back upon exiting. This then > got propogated here as well⁴ >  > >  > On top of that, there are countless advices on just increasing the `gc- > cons-threshold` (not inifitely increasing, just making some sane larger > value), that would surely reinforce an idea of just making GC run only on > idle, if one ever comes across such advice or just figures it out. > > What I meant was if people really disabled GC for the rest of their > session and got away with it.  But that was only a rhetorical question > to which the answer is clearly no.  I'm not sure where you got this answer from. The first link I referred to has a user which does exactly that, and it is a highly upvoted question with 4k views. To me that seem to imply the answer is "yes". > All the examples you cite have a > culprit - an application that produces too much garbage.  Identifying > those applications would be much better than working around them by > disabling GC, for example, while a user is in a minibuffer dialog.  That > latter case even must have an easy to identify responsible, just that > nobody cares.  Sure, I completely agree with you. But that is orthogonal to the problem of free()ed memory not actually being freed. > And remember that every cons eventually collected must > have been allocated first.  We always pay twice here. First of, glibc has per-thread cache (since 2.26 version, I think), specifically for the usecase of apps allcating and freeing memory too often. The cache is not affected by `malloc_trim()`, I was assured by people on #glibc IRC channel on that. Second, if Emacs indeed sees it's gonna allocate memory again right away, then it shouldn't have even freed the memory in the first place. No free — no malloc_trim().