From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Eager garbage collection Date: Mon, 16 Nov 2020 10:07:58 -0500 Message-ID: References: <87ft5akkjv.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24819"; 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: sbaugh@catern.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 16 16:09:07 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 1keg7t-0006Ib-9x for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Nov 2020 16:09:05 +0100 Original-Received: from localhost ([::1]:37724 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1keg7s-0007Mf-D3 for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Nov 2020 10:09:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keg6v-0006pv-17 for emacs-devel@gnu.org; Mon, 16 Nov 2020 10:08:05 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57423) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keg6s-00031r-BF for emacs-devel@gnu.org; Mon, 16 Nov 2020 10:08:04 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E0B18100257; Mon, 16 Nov 2020 10:08:00 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7EA59100091; Mon, 16 Nov 2020 10:07:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1605539279; bh=84BDaevK7fvduQmF2z6aSEvHwNYebFAcCy2K5xU7oEQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=pfi4pO6QJ+qhUG7bYMDy14J9kFgNamlECriiLh7DtPJmqIoyzEHaKSf1ginbp6/LI TRup7ZbPjL2QEgZEF2KaVfqzf4zd8eRK5WG91ae/XyjbHwvSdw0QiP9hxba5l7CAW/ suDg3cUim4mD0OA1CM+zRFmTbSAuX8ZH4V3+vQtywR3fHfhtzh/H/3lTiR6LAe1GYQ phvYqWPbICMOSwmr0sAxz/AJ+ZMahhhqCpXt6xa4JDGZIqq1/RUwyeVGsTvNyLeNlS fEzb9cnulRRoHvJ9mPFvPC0SDwo8lu3Wr1+Mq+c9ZFjIVcfsPNais0Syv4k5ed16+R T4zVl5sUK4Q+g== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 569B41202B0; Mon, 16 Nov 2020 10:07:59 -0500 (EST) In-Reply-To: <87ft5akkjv.fsf@catern.com> (sbaugh@catern.com's message of "Sun, 15 Nov 2020 23:11:32 -0500") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/16 10:08:01 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:259231 Archived-At: > Does this kind of change seem plausible? I'd be happy to include something like this yes. Some comments below: > +/* Like maybe_garbage_collect, but with the GC threshold halved as a > + way to GC eagerly. The GC threshold will be reset on our next call > + to maybe_garbage_collect. */ I think the second sentence deserves to be expanded a bit, explaining why it's OK not to restore the original values (why they'll be reset by the next call to maybe_garbage_collect and why nothing bad will happen until then). Alternatively, we could also just explicitly call `bump_consing_until_gc` in the else branch and skip the whole discussion. > +void > +maybe_garbage_collect_eagerly (void) > +{ > + if (bump_consing_until_gc (gc_cons_threshold/2, Vgc_cons_percentage) < 0) > + garbage_collect (); > +} If your Emacs session is moderately large, `gc_cons_threshold` will be irrelevant and it'll be Vgc_cons_percentage which will determine the gc_threshold. How 'bout we replace if (bump_consing_until_gc (gc_cons_threshold/2, Vgc_cons_percentage) < 0) with EMACS_INT since_gc = gc_threshold - consing_until_gc; if (since_gc > gc_threshold / N) where N could be 2 like you had (tho I could see argument for making it larger, e.g. some people may want to bump the normal threshold by say 5 and then use 10 here, so as to strongly bias Emacs to only ever run the GC while idle). > /* If there is still no input available, ask for GC. */ > if (!detect_input_pending_run_timers (0)) > - maybe_gc (); > + maybe_garbage_collect_eagerly (); > } This will cause an eager GC right after Emacs goes idle, which can happen while the user is actively typing. I think it would be preferable to run this from an idle timer to make sure that we run during an actual pause of incoming events. Your code effectively uses an idle-time of 0, and I'm not sure what idle-time we should use instead. Admittedly, using an idle time of 0 means we start the GC right at the beginning of the (potentially short) pause, which also makes it more likely that we'll have finished GC before the next event comes in. Stefan