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 11:23:43 +0300 Message-ID: <3f4f8b3034e9f52f48ec520f2732b1687bb24dbc.camel@yandex.ru> References: <83k0rz21dw.fsf@gnu.org> <331805c74fc5d3d412dd2065030b11fa3343710d.camel@yandex.ru> <8a91fc16f93298bca1281b43d6821ae3621376dc.camel@yandex.ru> <7ffacc5f-fc0e-a5f8-104d-2c0ae8e06953@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="40170"; 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 09:25:25 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 1l7DTZ-000AKh-6b for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 09:25:25 +0100 Original-Received: from localhost ([::1]:33632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7DTY-0006fO-50 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 03:25:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42052) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7DTC-0006cX-Sj for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 03:25:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53376) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l7DTC-00024W-Jq for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 03:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l7DTC-0003Gf-Fj for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 03:25: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 08:25: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.161234064612489 (code B ref 45200); Wed, 03 Feb 2021 08:25:02 +0000 Original-Received: (at 45200) by debbugs.gnu.org; 3 Feb 2021 08:24:06 +0000 Original-Received: from localhost ([127.0.0.1]:36689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7DSC-0003Ey-Cf for submit@debbugs.gnu.org; Wed, 03 Feb 2021 03:24:06 -0500 Original-Received: from forward104o.mail.yandex.net ([37.140.190.179]:43303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7DS8-0003Ei-Cd for 45200@debbugs.gnu.org; Wed, 03 Feb 2021 03:23:59 -0500 Original-Received: from iva1-c9520d34ceae.qloud-c.yandex.net (iva1-c9520d34ceae.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:7695:0:640:c952:d34]) by forward104o.mail.yandex.net (Yandex) with ESMTP id 045BB940395; Wed, 3 Feb 2021 11:23:49 +0300 (MSK) Original-Received: from iva6-2d18925256a6.qloud-c.yandex.net (iva6-2d18925256a6.qloud-c.yandex.net [2a02:6b8:c0c:7594:0:640:2d18:9252]) by iva1-c9520d34ceae.qloud-c.yandex.net (mxback/Yandex) with ESMTP id pf9sBNAi9G-NmHOlUJi; Wed, 03 Feb 2021 11:23:48 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1612340628; bh=ogWAbhvGPHRYWhSknX5xBVnKdlKTxHAEA7+IJSW8cPA=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=g0cbTTEdz8khg2oQi7HwxUirihf1Nx1FWT3PG8L+KZDH/GyA6PMnCFY31y+ThHK1d RhGJBfnZbM1tkMLEassdhLehloczdtZmNPjLqdu5a5eXQbRiWMB2x33TeHUYkYmeEL ksQqjcnLdNSfRU5jKMjO0JimemWKAWPBt71Xf/j4= Authentication-Results: iva1-c9520d34ceae.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by iva6-2d18925256a6.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id bbVdZmRHjM-Nlo4oFVg; Wed, 03 Feb 2021 11:23:47 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <7ffacc5f-fc0e-a5f8-104d-2c0ae8e06953@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:199181 Archived-At: On Wed, 2021-02-03 at 08:39 +0100, martin rudalics wrote: >  > Well, I didn't send the patches for my only benefit, but for benefit >  > of others people. The new ELisp function is something that not too >  > many people would benefit from, and I mean, including those who >  > disable GC. > > 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. >  > That is because it would be an opt-in feature, which you >  > need to know about to enable it, and not many will ever find out about >  > it. > > I wouldn't be afraid of that.  In the past months we had a sufficient > number of candidates caring about the memory consumption of their Emacs > sessions.  An opt-out feature OTOH would get us soon a couple of people > who decide that your feature is responsible for some new slowness and > recommend to throw it out.  So making this an opt-in feature and at the > same time giving some recommendations of what users can do when they > detect that their sessions consumes more memory than expected would be a > finely balanced solution IMO. Well, I have 2 things to say on that. First of, so far the impact seemed to be small. If one ever comes to blame the new feature, they surely should have actual measurements to support that hypothesis. Second, most importantly, what `malloc_trim(0)` does is it restores the correct behavior. I mean, what's the point of ever freeing memory if it's not freed, right? The problem we're dealing here with is an actual bug in glibc⁵. What this implies is that if the fix indeed hurts performance someplace, well, then it's that this place requires additional performance-related fixes. As opposed to just ignoring the bug because of performance got somewhere decreased. Things like, changing the slow algorithm, or modifying GC behavior for specific usecases… It is the general rule that correct behavior rarely correlates with good performance. You might for example omit locks in thread-heavy application, and you get better performance at cost of thread races. Things like that. --------- 1: https://emacs.stackexchange.com/questions/34342/is-there-any-downside-to-setting-gc-cons-threshold-very-high-and-collecting-ga 2: https://www.reddit.com/r/emacs/comments/4j828f/til_setq_gcconsthreshold_100000000/d34gbsp/?context=3 3: https://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/ 4: https://javaguirre.me/2016/10/19/fixing-my-performance-problems-on-emacs 5: https://sourceware.org/bugzilla/show_bug.cgi?id=27103