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 18:29:41 +0300 Message-ID: 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> <09cc70f14e90f6b13b51b0536fae76e87dfe3f42.camel@yandex.ru> <55be0318-c907-bf9b-d644-d88abb816871@gmx.at> <35163027-a5b7-4a6c-6700-69d34fecf451@gmx.at> <824625557ce288b0cbc3edd66ff730afd479b511.camel@yandex.ru> 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="28615"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.38.3 Cc: carlos@redhat.com, fweimer@redhat.com, dj@redhat.com, 45200@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 03 16:31:19 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 1l7K7j-0007LX-Oy for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 16:31:19 +0100 Original-Received: from localhost ([::1]:54812 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7K7i-0008Ty-RF for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Feb 2021 10:31:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7K6X-0007qL-Ku for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 10:30:09 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55313) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l7K6U-0005hu-8S for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 10:30:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l7K6U-0003qn-3U for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2021 10:30: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 15:30: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.161236619314762 (code B ref 45200); Wed, 03 Feb 2021 15:30:02 +0000 Original-Received: (at 45200) by debbugs.gnu.org; 3 Feb 2021 15:29:53 +0000 Original-Received: from localhost ([127.0.0.1]:38626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7K6K-0003q2-Sz for submit@debbugs.gnu.org; Wed, 03 Feb 2021 10:29:53 -0500 Original-Received: from forward106p.mail.yandex.net ([77.88.28.109]:39024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7K6H-0003pj-V7 for 45200@debbugs.gnu.org; Wed, 03 Feb 2021 10:29:51 -0500 Original-Received: from sas1-43b74f7725b7.qloud-c.yandex.net (sas1-43b74f7725b7.qloud-c.yandex.net [IPv6:2a02:6b8:c14:391a:0:640:43b7:4f77]) by forward106p.mail.yandex.net (Yandex) with ESMTP id 9802D1C80E0B; Wed, 3 Feb 2021 18:29:42 +0300 (MSK) Original-Received: from sas1-f4dc5f2fc86f.qloud-c.yandex.net (sas1-f4dc5f2fc86f.qloud-c.yandex.net [2a02:6b8:c08:cb28:0:640:f4dc:5f2f]) by sas1-43b74f7725b7.qloud-c.yandex.net (mxback/Yandex) with ESMTP id 2QJtszOois-TgH4EiU7; Wed, 03 Feb 2021 18:29:42 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1612366182; bh=9yx27pYdf2pENoAnClA7ZBbTfFjOcv6qBjMa/9wuavA=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=KqjRvjHSVrnQL/cfH5fwJ9E4IbUGgFK3M/JwEqPXuFzFz6vdpOvK6nuPAhERBUyt0 HKyAidwMnR7wTubizxHEul30UudwbnTqx0UOM2IJYVpcm6+xZ4m1R62lcp+ggkKZWg OhgIbctNEqW2hCl31U8ZR7i+aaOGxaZl4rbzKPkw= Authentication-Results: sas1-43b74f7725b7.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by sas1-f4dc5f2fc86f.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id lQhcgwPPir-TfoSHnpo; Wed, 03 Feb 2021 18:29:41 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: 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:199205 Archived-At: On Wed, 2021-02-03 at 10:15 -0500, Stefan Monnier wrote: > > Stefan, what do you think? Will it be okay if I implement a patch that runs > > `malloc_trim(0)` when Emacs is idle? > > That's yet another reason why we should provide that function to ELisp, > and then have ELisp decide when it's called (whether after GC, or on > idle or what). Okay, let's discuss this idea. It seems that running `malloc_trim(0)` on idle (let's say, after 10 seconds of idling, which implies a user might have switch to a browser, or something) should resolve all performance concerns. Especially given, measurements show it has pretty negligible impact even when located on return from GC. To answer you question in another email about memory benefits given default Emacs settings: well, today I tried creating a testcase that would reproduce problem with default settings, but haven't really succeeded at it. I have a testcase where Emacs without the patch has ≈20M more memory than the one with the patch, but that's pretty small difference, and offhand I didn't manage to get it increased any further. So, I'm thinking of wiring the functional of memory trimming to on-idle hook, without possibility to disable it. Given how small performance impact in this case would be, I see no reason to even implement an option to disable it. Thoughts?