From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Lisp-level macro to avoid excessive GC in memory-allocating code (was: Larger GC thresholds for non-interactive Emacs) Date: Fri, 01 Jul 2022 13:45:48 +0300 Message-ID: <83r135dsbn.fsf@gnu.org> References: <835yl910gp.fsf@gnu.org> <87wndndbhq.fsf@gmail.com> <83bkuzznws.fsf@gnu.org> <877d5mqmkh.fsf@localhost> <83y1y2utnd.fsf@gnu.org> <87r13up587.fsf@localhost> <83o7yyur0l.fsf@gnu.org> <87leu2p3nu.fsf@localhost> <83leu2uewn.fsf@gnu.org> <87r13qv701.fsf@localhost> <83bkuursya.fsf@gnu.org> <87h74l9jk8.fsf@localhost> <83bkutqb3z.fsf@gnu.org> <9778F176-E724-4E61-B0FB-327BCDD316C0@acm.org> <87sfo4epeo.fsf@localhost> <87bkurrc5e.fsf@localhost> <87v8shk1c5.fsf@localhost> <83wncxe4pr.fsf@gnu.org> <87k08xjmlm.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34494"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 01 12:48:43 2022 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 1o7ECY-0008l1-2H for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jul 2022 12:48:42 +0200 Original-Received: from localhost ([::1]:41580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o7ECU-0005B4-UB for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jul 2022 06:48:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45618) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7E9h-0003Qe-OT for emacs-devel@gnu.org; Fri, 01 Jul 2022 06:45:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57948) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7E9g-0003Rn-GI; Fri, 01 Jul 2022 06:45:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=x2E9N20D3MC3fTt6Kv82oI1R17uErfB3dSXHk6P5/Ic=; b=c4lr1+cB6Q4l 1AYDvcXybr/IhEvcy56x9L/lRH/r7H2GkmlUNhP/5ZAIAfxVh07okL8eDY9TMxheKshvOxBPdcJjB 6roLh5uCPEBxM5k58cTP6joIzUEoPdUUiiUJag4puO/0EoxJw8o6wT8WqfGcfvvH3FGAI77dLPHE6 dR0U4kFVK6QMR8ZiWnlojqenFdxPptJkITXAkS89P7n2lJzJptSVLNWcYhzN9GICziNwSrtrkqWin 3Q5DenOjfpa9v1Zj9Uk+9R9JNWCtRiFtHqC7E5wUEh2HrxHy2BGmfxOAnlbSmC2jugumpoDKDQQ5J Vw0S8UsGZg/GzF9l1P76nQ==; Original-Received: from [87.69.77.57] (port=4895 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7E9a-0007Z8-4q; Fri, 01 Jul 2022 06:45:38 -0400 In-Reply-To: <87k08xjmlm.fsf@localhost> (message from Ihor Radchenko on Fri, 01 Jul 2022 15:52:53 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:291773 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, mattiase@acm.org, theophilusx@gmail.com, > rms@gnu.org, acm@muc.de, emacs-devel@gnu.org > Date: Fri, 01 Jul 2022 15:52:53 +0800 > > Eli Zaretskii writes: > > > Please don't forget that GC doesn't only collects unused Lisp objects, > > it also does other useful memory-management related tasks. It > > compacts buffer text and strings, and it frees unused slots in various > > caches (font cache, image cache, etc.). You can find in the archives > > discussions where innocently-looking code could cause Emacs run out of > > memory because it used too many fonts without flushing the font cache > > (any program that works on the list of fonts returned by the likes of > > x-list-fonts is in danger of bumping into that). > > Then, if we decide to implement the macro I am suggesting, such macro > should not affect memory allocation of such sensitive objects: font > cache, image cache, etc. Why not? The same could happen with those cached objects. And doing these jobs does take CPU time. > 1. In addition to directly bumping the TOTAL counter of newly allocated > memory, we can introduce a new LOCAL counter holding recent > allocations within current sexp. > 2. Every time we return from a sexp/self-quoting object into assignment, > if we are inside the proposed macro and also assigning value to one > of the pre-defined symbols, increase the upper LOCAL counter in the > parent sexp. Otherwise, do not change the upper LOCAL counter. > 3. Perform GC according to TOTAL-LOCAL threshold value. > 4. When exiting the macro, set LOCAL to 0, unless inside another such > macro. Is this aligned with what the implementation of the Lisp interpreter actually does? I'm not sure we know, where we allocate memory for Lisp data, whether we are going to bind some variable to the produced data. Thus "count recent allocations within the current sexp" sounds like non-trivial to implement. And what do you mean by "pre-defined symbols"? what makes a symbol "pre-defined"? I also am not sure we have the "parent sexp" in hand, but I'll let experts on the Lisp interpreter to comment on that.