[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