From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Eager garbage collection Date: Wed, 18 Nov 2020 15:47:30 +0000 Message-ID: References: <20201118002050.16426-1-sbaugh@catern.com> <87wnyik801.fsf@catern.com> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34174"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 18 16:48:48 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kfPhO-0008kM-UC for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Nov 2020 16:48:46 +0100 Original-Received: from localhost ([::1]:38740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kfPhO-0000OW-06 for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Nov 2020 10:48:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfPgJ-00081A-0f for emacs-devel@gnu.org; Wed, 18 Nov 2020 10:47:39 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:61366) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfPgE-0005xX-Sw for emacs-devel@gnu.org; Wed, 18 Nov 2020 10:47:38 -0500 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTP id 0AIFlU8U021918; Wed, 18 Nov 2020 15:47:30 GMT In-Reply-To: <87wnyik801.fsf@catern.com> (Spencer Baugh's message of "Wed, 18 Nov 2020 10:19:26 -0500") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/18 10:30:26 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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.io gmane.emacs.devel:259355 Archived-At: Spencer Baugh writes: > Andrea Corallo writes: >> My question is, what is the advantage of this implementation respect the >> pure Lisp one we have? >> >> >> >> AFAIU they achieve the same. If that's the case I indeed prefer the >> Lisp one as simpler and easier to extend. > > The core necessary thing that requires C changes is making a garbage > collection function which "maybe" does a garbage collect. > > gcmh.el always does a full garbage collection when idle, even if there's > no garbage. That will hurt responsiveness, especially with a very large > heap (as gcmh configures), because GC takes time proportional to the > size of the heap, not the amount of garbage. Correct that was a conscious decision, in the assumption that the user is unlikely to be interacting with Emacs at that moment I deemed was good to clean-up all the garbage unconditionally. > Possibly, we could rely on the fact that maybe_gc gets called > automatically as part of Lisp evaluation. Then we'd just want to ensure > that GC happens eagerly, which we could do by lowering gc-cons-threshold > while idle. But that's excessively magical, I would say. There is nothing magical about and I believe is how it should be implemented. Setting a lower threshold there also prevents functions that may be executed by timers to leave the heap with garbage just before the user start the next command. If we don't like the idle unconditional garbage collection of the GCMH we can just remove it. At that point the only thing we should expose from C is the last GC elapsed time. Andrea