GNU bug report logs - #79346
igc: PolicyShouldCollectWorld

Previous Next

Package: emacs;

Reported by: Helmut Eller <eller.helmut <at> gmail.com>

Date: Sat, 30 Aug 2025 11:55:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 79346 <at> debbugs.gnu.org
Subject: bug#79346: igc: PolicyShouldCollectWorld
Date: Sat, 06 Sep 2025 09:45:04 +0300
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: gerd.moellmann <at> gmail.com,  79346 <at> debbugs.gnu.org
> Date: Fri, 05 Sep 2025 18:57:35 +0200
> 
> On Fri, Sep 05 2025, Eli Zaretskii wrote:
> 
> [...]
> >> Below is a patch that does this.
> >> 
> >> The idle timer waits 2 seconds, before it calls mps_arena_step.  As
> >> usual, "idle time" is the time since the last command completed, i.e. 2
> >> seconds must pass after a command before the idle timer fires.  (Other
> >> timers or process filters don't reset "idle time"; only new commands
> >> do.)  I think that should avoid the problem that I've seen where
> >> opportunistic GC was started while I was in the middle of typing
> >> something.
> >> 
> >> The code uses a constant to predict the idle time; maybe one could to
> >> something a bit more clever; not sure if that would be worth the
> >> trouble.
> >
> > AFAIU, this makes GC-on-idle run off an idle timer, instead of using
> > internal implementation in C, is that right?
> 
> Yes, right.
> 
> > If so, I'm not very happy doing this, as the default mechanism.
> > Timers are hard to reason about, when other timers, let alone other
> > Lisp threads, are present, and the result might be more complex
> > system, which is harder to understand and maintain.
> >
> > It is okay to allow this to run off an idle timer, as an opt-in
> > feature.  But let's leave the internal implementation as the default,
> > at least for now.
> 
> The patch was not committed, AFAIK.

I know.  I guess I'm asking to please rework it as an optional
feature, instead of an unconditional replacement.  Is that possible
and reasonably feasible?




This bug report was last modified today.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.