emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eager garbage collection


From: Stefan Monnier
Subject: Re: Eager garbage collection
Date: Mon, 16 Nov 2020 10:07:58 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]