Re: Eager garbage collection

[Andrea Corallo]

Spencer Baugh <sbaugh@catern.com> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>> My question is, what is the advantage of this implementation respect the
>> pure Lisp one we have?
>>
>> <https://gitlab.com/koral/gcmh/-/blob/master/gcmh.el>
>>
>> AFAIU they achieve the same.  If that's the case I indeed prefer the
>> Lisp one as simpler and easier to extend.
>
> The core necessary thing that requires C changes is making a garbage
> collection function which "maybe" does a garbage collect.
>
> gcmh.el always does a full garbage collection when idle, even if there's
> no garbage.  That will hurt responsiveness, especially with a very large
> heap (as gcmh configures), because GC takes time proportional to the
> size of the heap, not the amount of garbage.

Correct that was a conscious decision, in the assumption that the user
is unlikely to be interacting with Emacs at that moment I deemed was
good to clean-up all the garbage unconditionally.

> Possibly, we could rely on the fact that maybe_gc gets called
> automatically as part of Lisp evaluation.  Then we'd just want to ensure
> that GC happens eagerly, which we could do by lowering gc-cons-threshold
> while idle.  But that's excessively magical, I would say.

There is nothing magical about and I believe is how it should be
implemented.

Setting a lower threshold there also prevents functions that may be
executed by timers to leave the heap with garbage just before the user
start the next command.

If we don't like the idle unconditional garbage collection of the GCMH
we can just remove it.  At that point the only thing we should expose
from C is the last GC elapsed time.

  Andrea