Re: Lisp-level macro to avoid excessive GC in memory-allocating code (was: Larger GC thresholds for non-interactive Emacs)

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> 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 <eliz@gnu.org> 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.