GNU bug report logs -
#79346
igc: PolicyShouldCollectWorld
Previous Next
To reply to this bug, email your comments to 79346 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 30 Aug 2025 11:55:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Helmut Eller <eller.helmut <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 30 Aug 2025 11:55:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When I set igc-step-interval like so
(setq igc-step-interval 0.05)
and in GDB add a breakpoint in PolicyShouldCollectWorld with
dprintf policy.c:195,"availableTime: %f collectionTime: %f sinceLastWorldCollect: %f", availableTime, collectionTime, sinceLastWorldCollect
[With the debug build of MPS. availableTime is not available in
optimized builds.]
I see output like:
availableTime: 50000.000000 collectionTime: 1.078059 sinceLastWorldCollect: 6.623319
It seems that availableTime and collectionTime use different units:
availableTime is in clocks while collectionTime is in seconds.
So the test availableTime > collectionTime doesn't make much sense.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 30 Aug 2025 18:38:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Sat, 30 Aug 2025 13:53:50 +0200
>
> When I set igc-step-interval like so
>
> (setq igc-step-interval 0.05)
>
> and in GDB add a breakpoint in PolicyShouldCollectWorld with
>
> dprintf policy.c:195,"availableTime: %f collectionTime: %f sinceLastWorldCollect: %f", availableTime, collectionTime, sinceLastWorldCollect
>
> [With the debug build of MPS. availableTime is not available in
> optimized builds.]
>
> I see output like:
>
> availableTime: 50000.000000 collectionTime: 1.078059 sinceLastWorldCollect: 6.623319
>
> It seems that availableTime and collectionTime use different units:
> availableTime is in clocks while collectionTime is in seconds.
>
> So the test availableTime > collectionTime doesn't make much sense.
Since I don't see such comparison anywhere in Emacs, I presume you are
talking about a bug in MPS? Or what did I miss?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sun, 31 Aug 2025 07:33:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 79346 <at> debbugs.gnu.org (full text, mbox):
On Sat, Aug 30 2025, Eli Zaretskii wrote:
>> It seems that availableTime and collectionTime use different units:
>> availableTime is in clocks while collectionTime is in seconds.
>>
>> So the test availableTime > collectionTime doesn't make much sense.
>
> Since I don't see such comparison anywhere in Emacs, I presume you are
> talking about a bug in MPS? Or what did I miss?
Yes, the comparison is in PolicyShouldCollectWorld. The call chain is
usually: timer_check_2 -> igc_on_idle -> mps_arena_step -> ArenaStep ->
PolicyShouldCollectWorld.
It looks like the bug is in ArenaStep: it should divide the by
clocks_per_second before calling PolicyShouldCollectWorld.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sun, 31 Aug 2025 08:37:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: 79346 <at> debbugs.gnu.org
> Date: Sun, 31 Aug 2025 09:32:24 +0200
>
> On Sat, Aug 30 2025, Eli Zaretskii wrote:
>
> >> It seems that availableTime and collectionTime use different units:
> >> availableTime is in clocks while collectionTime is in seconds.
> >>
> >> So the test availableTime > collectionTime doesn't make much sense.
> >
> > Since I don't see such comparison anywhere in Emacs, I presume you are
> > talking about a bug in MPS? Or what did I miss?
>
> Yes, the comparison is in PolicyShouldCollectWorld. The call chain is
> usually: timer_check_2 -> igc_on_idle -> mps_arena_step -> ArenaStep ->
> PolicyShouldCollectWorld.
>
> It looks like the bug is in ArenaStep: it should divide the by
> clocks_per_second before calling PolicyShouldCollectWorld.
What does this affect in Emacs?
And is this relevant to using a non-debug build of the library?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sun, 31 Aug 2025 09:23:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sun, Aug 31 2025, Eli Zaretskii wrote:
>> It looks like the bug is in ArenaStep: it should divide the by
>> clocks_per_second before calling PolicyShouldCollectWorld.
>
> What does this affect in Emacs?
This affects how often MPS begins opportunistic GC, i.e. it affects only
sessions where igc-step-interval > 0.
Because of the bug, full collections are started more frequently because
availableTime > collectionTime is true more often. (availableTime is
10^6 times bigger than it should be.)
The documentation of PolicyShouldCollectWorld says that it starts a full
collection only if it expects that the full collection can be completed
within availableTime (= igc-step-interval) and if enough time (= per
process time) has passed since the last full collection.
> And is this relevant to using a non-debug build of the library?
Yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sun, 31 Aug 2025 09:31:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Sun, 31 Aug 2025 11:21:41 +0200
>
> On Sun, Aug 31 2025, Eli Zaretskii wrote:
>
> >> It looks like the bug is in ArenaStep: it should divide the by
> >> clocks_per_second before calling PolicyShouldCollectWorld.
> >
> > What does this affect in Emacs?
>
> This affects how often MPS begins opportunistic GC, i.e. it affects only
> sessions where igc-step-interval > 0.
>
> Because of the bug, full collections are started more frequently because
> availableTime > collectionTime is true more often. (availableTime is
> 10^6 times bigger than it should be.)
>
> The documentation of PolicyShouldCollectWorld says that it starts a full
> collection only if it expects that the full collection can be completed
> within availableTime (= igc-step-interval) and if enough time (= per
> process time) has passed since the last full collection.
>
> > And is this relevant to using a non-debug build of the library?
>
> Yes.
OK, thanks. I guess it will be interesting to see what happens if
people use a patched MPS with this bug fixed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Thu, 04 Sep 2025 03:16:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 79346 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Helmut Eller <eller.helmut <at> gmail.com>
>> Date: Sun, 31 Aug 2025 11:21:41 +0200
>>
>> On Sun, Aug 31 2025, Eli Zaretskii wrote:
>>
>> >> It looks like the bug is in ArenaStep: it should divide the by
>> >> clocks_per_second before calling PolicyShouldCollectWorld.
>> >
>> > What does this affect in Emacs?
>>
>> This affects how often MPS begins opportunistic GC, i.e. it affects only
>> sessions where igc-step-interval > 0.
>>
>> Because of the bug, full collections are started more frequently because
>> availableTime > collectionTime is true more often. (availableTime is
>> 10^6 times bigger than it should be.)
>>
>> The documentation of PolicyShouldCollectWorld says that it starts a full
>> collection only if it expects that the full collection can be completed
>> within availableTime (= igc-step-interval) and if enough time (= per
>> process time) has passed since the last full collection.
>>
>> > And is this relevant to using a non-debug build of the library?
>>
>> Yes.
>
> OK, thanks. I guess it will be interesting to see what happens if
> people use a patched MPS with this bug fixed.
Good find, Helmut. There used to be a comment in arena_step wondering
what's going on, but it got removed, apparently. Does this look right?
[0001-Fix-bug-calculating-available-time-in-ArenaStep.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Thu, 04 Sep 2025 07:33:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 79346 <at> debbugs.gnu.org (full text, mbox):
On Thu, Sep 04 2025, Gerd Möllmann wrote:
> Good find, Helmut. There used to be a comment in arena_step wondering
> what's going on, but it got removed, apparently. Does this look right?
LGTM.
BTW, in igc_on_idle, arena_step is called repeatedly as long as
work_done is true. Note that buffer_step sets work_done to true until
the buffer iterator is exhausted. So arena_step is called for each
buffer. That seems a bit excessive.
What would you think of making mps_arena_step and perhaps buffer_step
available from Lisp so that those things can be called from Lisp-level
idle timers?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Thu, 04 Sep 2025 07:47:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Helmut Eller <eller.helmut <at> gmail.com> writes:
> On Thu, Sep 04 2025, Gerd Möllmann wrote:
>> Good find, Helmut. There used to be a comment in arena_step wondering
>> what's going on, but it got removed, apparently. Does this look right?
>
> LGTM.
I've also made an issue for that
https://github.com/Ravenbrook/mps/issues/308
> BTW, in igc_on_idle, arena_step is called repeatedly as long as
> work_done is true. Note that buffer_step sets work_done to true until
> the buffer iterator is exhausted. So arena_step is called for each
> buffer. That seems a bit excessive.
>
> What would you think of making mps_arena_step and perhaps buffer_step
> available from Lisp so that those things can be called from Lisp-level
> idle timers?
Sounds like a good idea.
I think there quite some areas one could and probably should play more
with (ignoring the fact that Andrea made it a feature branch; maybe we
should rename it back to a scratch branch? :-)).
Anyway, the number and size of generations is such a thing. I've been
playing with that on and off and I think I found a setting that works
noticeably smoother than the default. I've made me something that makes
it easier to play with:
static bool
read_gens (mps_gen_param_s **gens, int *ngens)
{
const char *env = getenv ("EMACS_IGC_GENS");
if (env == NULL)
return false;
const char *verbose = getenv ("EMACS_IGC_VERBOSE");
const char *end = env + strlen (env);
static struct mps_gen_param_s parms[10];
*ngens = 0;
*gens = parms;
for (int i = 0; i < ARRAYELTS (parms) && env < end; ++i)
{
int nchars;
if (sscanf (env, "%zu %lf%n", &parms[i].mps_capacity,
&parms[i].mps_mortality, &nchars) == 2)
{
if (verbose)
fprintf (stderr, "gen %d: %zu %lf\n", i, parms[i].mps_capacity,
parms[i].mps_mortality);
env += nchars;
++*ngens;
}
}
return true;
}
static void
make_arena (struct igc *gc)
{
mps_res_t res;
MPS_ARGS_BEGIN (args)
{
res = mps_arena_create_k (&gc->arena, mps_arena_class_vm (), args);
}
MPS_ARGS_END (args);
IGC_CHECK_RES (res);
mps_gen_param_s *gens;
int ngens;
if (!read_gens (&gens, &ngens))
{
static mps_gen_param_s default_gens[] = {
{ 256000, 0.8 }, { 256000, 0.6 }, { 256000, 0.4 }, { 2 * 256000, 0.2 }
};
gens = default_gens;
ngens = ARRAYELTS (default_gens);
}
res = mps_chain_create (&gc->chain, gc->arena, ngens, gens);
IGC_CHECK_RES (res);
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Thu, 04 Sep 2025 20:07:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 79346 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Sep 04 2025, Gerd Möllmann wrote:
> Helmut Eller <eller.helmut <at> gmail.com> writes:
[...]
>> What would you think of making mps_arena_step and perhaps buffer_step
>> available from Lisp so that those things can be called from Lisp-level
>> idle timers?
>
> Sounds like a good idea.
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.
Regarding bug#76505 (or https://github.com/Ravenbrook/mps/issues/305),
I now think that it's safe to call mps_arena_step with multiplier=0:
The expression (availableEnd - now) never overflows because the
invariant now <= intervalEnd <= availableEnd holds.
[0001-Call-mps_arena_step-from-a-Lisp-idle-timer.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Thu, 04 Sep 2025 20:14:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 79346 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Sep 04 2025, Gerd Möllmann wrote:
[...]
> Anyway, the number and size of generations is such a thing. I've been
> playing with that on and off and I think I found a setting that works
> noticeably smoother than the default.
It seems to me that the arena pause_time parameter must be tuned
together with the size(s) of the generation(s). Smaller generations
require shorter pause_times. I gravitate towards 10MB for the first
generation and 10 milliseconds pause time. My feeling is that something
in the order of 10MB should work better than 100MB. Of course, this
requires measurements to be sure.
> I've made me something that makes it easier to play with:
I've been using this:
[0001-Add-igc_params.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 03:29:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Helmut Eller <eller.helmut <at> gmail.com> writes:
> On Thu, Sep 04 2025, Gerd Möllmann wrote:
>
>> Helmut Eller <eller.helmut <at> gmail.com> writes:
> [...]
>>> What would you think of making mps_arena_step and perhaps buffer_step
>>> available from Lisp so that those things can be called from Lisp-level
>>> idle timers?
>>
>> Sounds like a good idea.
>
> Below is a patch that does this.
Thanks. I have that in my Emacs now.
> 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.
Okay.
> 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.
I'm already playing a bit with this
(setq igc--step-interval 0.02 igc--idle-delay 1.0)
The step interval is what I've been using before, together with the
generations I mentioned. Don't know about the delay.
> Regarding bug#76505 (or https://github.com/Ravenbrook/mps/issues/305),
> I now think that it's safe to call mps_arena_step with multiplier=0:
> The expression (availableEnd - now) never overflows because the
> invariant now <= intervalEnd <= availableEnd holds.
Hadn't noticed that one, and it's a bit tldr. Maybe it's worth adding
something to the MPS issue? Or maybe not, don't know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 03:47:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Helmut Eller <eller.helmut <at> gmail.com> writes:
> On Thu, Sep 04 2025, Gerd Möllmann wrote:
>
> [...]
>> Anyway, the number and size of generations is such a thing. I've been
>> playing with that on and off and I think I found a setting that works
>> noticeably smoother than the default.
>
> It seems to me that the arena pause_time parameter must be tuned
> together with the size(s) of the generation(s).
That's true. I forgot to mention the 0.02s I am using.
> Smaller generations require shorter pause_times. I gravitate towards
> 10MB for the first generation and 10 milliseconds pause time. My
> feeling is that something in the order of 10MB should work better than
> 100MB. Of course, this requires measurements to be sure.
:-)
>
>> I've made me something that makes it easier to play with:
>
> I've been using this:
Thanks. I'll try to get that into my Emacs a bit later because I have
some changes here that lead to conflicts.
Concerning feature/igc, I've come to the conclusion that it's probably
best for my peace when I ignore its existence and don't push anything
there anymore, either your changes or mine.
I could make a new branch though if you like. Just tell.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 06:35:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79346 <at> debbugs.gnu.org
> Date: Thu, 04 Sep 2025 22:05:55 +0200
>
> On Thu, Sep 04 2025, Gerd Möllmann wrote:
>
> > Helmut Eller <eller.helmut <at> gmail.com> writes:
> [...]
> >> What would you think of making mps_arena_step and perhaps buffer_step
> >> available from Lisp so that those things can be called from Lisp-level
> >> idle timers?
> >
> > Sounds like a good idea.
>
> 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?
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.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 06:37:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79346 <at> debbugs.gnu.org
> Date: Thu, 04 Sep 2025 22:12:55 +0200
>
> On Thu, Sep 04 2025, Gerd Möllmann wrote:
>
> [...]
> > Anyway, the number and size of generations is such a thing. I've been
> > playing with that on and off and I think I found a setting that works
> > noticeably smoother than the default.
>
> It seems to me that the arena pause_time parameter must be tuned
> together with the size(s) of the generation(s). Smaller generations
> require shorter pause_times. I gravitate towards 10MB for the first
> generation and 10 milliseconds pause time. My feeling is that something
> in the order of 10MB should work better than 100MB. Of course, this
> requires measurements to be sure.
Not sure if I make sense, but 10 ms of pause for GC sounds an awful
lot to me. Would 1 ms or 2 ms be reasonable? They should be
imperceptible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 16:51:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 79346 <at> debbugs.gnu.org (full text, mbox):
>> I've been using this:
>
> Thanks. I'll try to get that into my Emacs a bit later because I have
> some changes here that lead to conflicts.
Using environment variables is probably better anyway. Eli doesn't want
to add command line args for the sake of MPS and with environment
variables its easier to keep this inside igc.c.
> Concerning feature/igc, I've come to the conclusion that it's probably
> best for my peace when I ignore its existence and don't push anything
> there anymore, either your changes or mine.
I suppose it would also be best for my peace :-) ...
> I could make a new branch though if you like. Just tell.
... but I don't quite see how we should make progress without some
shared branch.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 16:52:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> Hadn't noticed that one, and it's a bit tldr. Maybe it's worth adding
> something to the MPS issue?
Done.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 16:58:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 79346 <at> debbugs.gnu.org (full text, mbox):
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.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 17:09:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 79346 <at> debbugs.gnu.org (full text, mbox):
On Fri, Sep 05 2025, Eli Zaretskii wrote:
[...]
>> It seems to me that the arena pause_time parameter must be tuned
>> together with the size(s) of the generation(s). Smaller generations
>> require shorter pause_times. I gravitate towards 10MB for the first
>> generation and 10 milliseconds pause time. My feeling is that something
>> in the order of 10MB should work better than 100MB. Of course, this
>> requires measurements to be sure.
>
> Not sure if I make sense,
No, you don't :-)
> but 10 ms of pause for GC sounds an awful
> lot to me.
The current value of the parameter is 100ms.
> Would 1 ms or 2 ms be reasonable? They should be imperceptible.
That probably below MPS's sweet spot. In my limited experiments, 16MB
with 10ms had the lowest overhead.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 18:06:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Helmut Eller <eller.helmut <at> gmail.com> writes:
>>> I've been using this:
>>
>> Thanks. I'll try to get that into my Emacs a bit later because I have
>> some changes here that lead to conflicts.
>
> Using environment variables is probably better anyway. Eli doesn't want
> to add command line args for the sake of MPS and with environment
> variables its easier to keep this inside igc.c.
Okay. Good for me, less work :-).
>
>> Concerning feature/igc, I've come to the conclusion that it's probably
>> best for my peace when I ignore its existence and don't push anything
>> there anymore, either your changes or mine.
>
> I suppose it would also be best for my peace :-) ...
>
>> I could make a new branch though if you like. Just tell.
>
> ... but I don't quite see how we should make progress without some
> shared branch.
I've branched a new scratch/igc2 from feature/igc for more "freestyle"
changes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 18:07:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Helmut Eller <eller.helmut <at> gmail.com> writes:
>> Hadn't noticed that one, and it's a bit tldr. Maybe it's worth adding
>> something to the MPS issue?
>
> Done.
👍
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Fri, 05 Sep 2025 18:56:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> AFAIU, this makes GC-on-idle run off an idle timer, instead of using
> internal implementation in C, is that 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.
Is it necessary to have "GC-on-idle"?
If not, I think it's OK to have it implemented only in Lisp.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 06:44:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79346 <at> debbugs.gnu.org
> Date: Fri, 05 Sep 2025 18:50:43 +0200
>
> >> I've been using this:
> >
> > Thanks. I'll try to get that into my Emacs a bit later because I have
> > some changes here that lead to conflicts.
>
> Using environment variables is probably better anyway. Eli doesn't want
> to add command line args for the sake of MPS and with environment
> variables its easier to keep this inside igc.c.
I don't like environment variables either: they get in the way when
you run Emacs from within another Emacs, in which case the two Emacs
sessions might use different Emacs builds and versions. Using
environment variables for debugging purposes might be semi-okay, but
people should keep the above problem in mind when they do it.
> > Concerning feature/igc, I've come to the conclusion that it's probably
> > best for my peace when I ignore its existence and don't push anything
> > there anymore, either your changes or mine.
>
> I suppose it would also be best for my peace :-) ...
If people who are working on igc abandon the branch, I don't see how
we can ever land this on master. Of course, if that is also better
for your peace, then so be it...
> > I could make a new branch though if you like. Just tell.
>
> ... but I don't quite see how we should make progress without some
> shared branch.
Exactly. And another branch in the repository will only muddy the
waters and make landing this on master harder, if not impossible.
Personally, I will be very sad if this work gets abandoned, but I
cannot do anything when people express feelings like those expressed
above. It's eventually up to those who work on the feature and are
motivated to get it into mainline.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 06:46:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 06:57:03 GMT)
Full text and
rfc822 format available.
Message #77 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79346 <at> debbugs.gnu.org
> Date: Fri, 05 Sep 2025 20:05:26 +0200
>
> I've branched a new scratch/igc2 from feature/igc for more "freestyle"
> changes.
Will someone merge from that branch to feature/igc? Or is this a
completely independent effort?
IOW, what is the intended use of this new branch, and how, if at all
will it fit into the work on adding igc to Emacs?
For example, if I have an igc-related change to install, on which of
the two branches should I do that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 07:02:04 GMT)
Full text and
rfc822 format available.
Message #80 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Helmut Eller <eller.helmut <at> gmail.com>, gerd.moellmann <at> gmail.com,
> 79346 <at> debbugs.gnu.org
> Date: Fri, 05 Sep 2025 14:54:54 -0400
>
> > AFAIU, this makes GC-on-idle run off an idle timer, instead of using
> > internal implementation in C, is that 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.
>
> Is it necessary to have "GC-on-idle"?
I don't know. The original implementation did have it.
> If not, I think it's OK to have it implemented only in Lisp.
If it becomes an optional feature, and if having it is not deemed
necessary, I'm okay with that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 07:03:03 GMT)
Full text and
rfc822 format available.
Message #83 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79346 <at> debbugs.gnu.org
>> Date: Fri, 05 Sep 2025 20:05:26 +0200
>>
>> I've branched a new scratch/igc2 from feature/igc for more "freestyle"
>> changes.
>
> Will someone merge from that branch to feature/igc? Or is this a
> completely independent effort?
>
> IOW, what is the intended use of this new branch, and how, if at all
> will it fit into the work on adding igc to Emacs?
>
> For example, if I have an igc-related change to install, on which of
> the two branches should I do that?
ATM, it's thought of a place where one can experiment with things
without being faced with bureaucratic hurdles, so to speak. Depends on
whether Helmut finds that useful, otherwise I'd delete it again.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 07:41:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Helmut Eller <eller.helmut <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79346 <at> debbugs.gnu.org
>> Date: Fri, 05 Sep 2025 18:50:43 +0200
>>
>> >> I've been using this:
>> >
>> > Thanks. I'll try to get that into my Emacs a bit later because I have
>> > some changes here that lead to conflicts.
>>
>> Using environment variables is probably better anyway. Eli doesn't want
>> to add command line args for the sake of MPS and with environment
>> variables its easier to keep this inside igc.c.
>
> I don't like environment variables either: they get in the way when
> you run Emacs from within another Emacs, in which case the two Emacs
> sessions might use different Emacs builds and versions. Using
> environment variables for debugging purposes might be semi-okay, but
> people should keep the above problem in mind when they do it.
>
>> > Concerning feature/igc, I've come to the conclusion that it's probably
>> > best for my peace when I ignore its existence and don't push anything
>> > there anymore, either your changes or mine.
>>
>> I suppose it would also be best for my peace :-) ...
>
> If people who are working on igc abandon the branch, I don't see how
> we can ever land this on master. Of course, if that is also better
> for your peace, then so be it...
>
>> > I could make a new branch though if you like. Just tell.
>>
>> ... but I don't quite see how we should make progress without some
>> shared branch.
>
> Exactly. And another branch in the repository will only muddy the
> waters and make landing this on master harder, if not impossible.
>
> Personally, I will be very sad if this work gets abandoned, but I
> cannot do anything when people express feelings like those expressed
> above. It's eventually up to those who work on the feature and are
> motivated to get it into mainline.
From what I see in git, as a bystander, either more or less everyone
involved has lost interest, or it's considered stable, and there's not
much more to do. Or a mixture of that. Considering that I haven't heard
of Stefan Kangas and Andrea for quite some time after initial
"enthusiasm", I think that at least these two have lost interest.
For me it looks like it either lands in master soon, or it'll inevitably
bit-rot.
Maybe sad, don't know, I have no hard feelings about that, but OTOH,
it's also only another anecdote in the 40 years of Emacs. And - if
people really have lost interest, maybe it's good if it gets abandoned
before it lands and then is another unmaintained feature like some GUI
front-ends, multi-tty and whatnot.
Just my 2 cents.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 07:44:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: eller.helmut <at> gmail.com, 79346 <at> debbugs.gnu.org
> Date: Sat, 06 Sep 2025 09:02:21 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79346 <at> debbugs.gnu.org
> >> Date: Fri, 05 Sep 2025 20:05:26 +0200
> >>
> >> I've branched a new scratch/igc2 from feature/igc for more "freestyle"
> >> changes.
> >
> > Will someone merge from that branch to feature/igc? Or is this a
> > completely independent effort?
> >
> > IOW, what is the intended use of this new branch, and how, if at all
> > will it fit into the work on adding igc to Emacs?
> >
> > For example, if I have an igc-related change to install, on which of
> > the two branches should I do that?
>
> ATM, it's thought of a place where one can experiment with things
> without being faced with bureaucratic hurdles, so to speak. Depends on
> whether Helmut finds that useful, otherwise I'd delete it again.
What "bureaucratic hurdles" are those?
Also, does this mean this branch is only for Helmut (and maybe
yourself) to use, and others should not push anything there without
talking to you first?
And my question about merges still stands, in case this branch will
get some changes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 07:49:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
SW>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: eller.helmut <at> gmail.com, 79346 <at> debbugs.gnu.org
>> Date: Sat, 06 Sep 2025 09:02:21 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79346 <at> debbugs.gnu.org
>> >> Date: Fri, 05 Sep 2025 20:05:26 +0200
>> >>
>> >> I've branched a new scratch/igc2 from feature/igc for more "freestyle"
>> >> changes.
>> >
>> > Will someone merge from that branch to feature/igc? Or is this a
>> > completely independent effort?
>> >
>> > IOW, what is the intended use of this new branch, and how, if at all
>> > will it fit into the work on adding igc to Emacs?
>> >
>> > For example, if I have an igc-related change to install, on which of
>> > the two branches should I do that?
>>
>> ATM, it's thought of a place where one can experiment with things
>> without being faced with bureaucratic hurdles, so to speak. Depends on
>> whether Helmut finds that useful, otherwise I'd delete it again.
>
> What "bureaucratic hurdles" are those?
A feature branch has some rules to follow, I'd guess.
>
> Also, does this mean this branch is only for Helmut (and maybe
> yourself) to use, and others should not push anything there without
> talking to you first?
Yes.
> And my question about merges still stands, in case this branch will
> get some changes.
No automatic merges from there to feature/igc.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 14:15:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> From what I see in git, as a bystander, either more or less everyone
> involved has lost interest, or it's considered stable, and there's not
> much more to do.
Just my ¢2. I've been daily-driving feature/igc for few months now, and
other than couple of crashes early on, it has been pretty smooth sailing
for past couple of months at least.
I'd very much like to see it land in master, hopefully in time for next
release, even if igc isn't enabled by default. I'm not particularly fond
of running master day-to-day, but am very much willing to build stable
with different flag for igc. My distro of choice can easily support both
variants (already does for emacs-nox and pgtk) and I will be happy to
add and maintain another variant for igc.
Anyway, a lot of work has been poured into feature/igc, I can attest to
its stability (for what its worth) and would really like to see it
merged.
Thanks,
Payas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 14:48:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Payas Relekar <relekarpayas <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79346 <at> debbugs.gnu.org, Helmut Eller
> <eller.helmut <at> gmail.com>
> Date: Sat, 06 Sep 2025 19:43:53 +0530
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> > From what I see in git, as a bystander, either more or less everyone
> > involved has lost interest, or it's considered stable, and there's not
> > much more to do.
>
> Just my ¢2. I've been daily-driving feature/igc for few months now, and
> other than couple of crashes early on, it has been pretty smooth sailing
> for past couple of months at least.
>
> I'd very much like to see it land in master, hopefully in time for next
> release, even if igc isn't enabled by default. I'm not particularly fond
> of running master day-to-day, but am very much willing to build stable
> with different flag for igc. My distro of choice can easily support both
> variants (already does for emacs-nox and pgtk) and I will be happy to
> add and maintain another variant for igc.
>
> Anyway, a lot of work has been poured into feature/igc, I can attest to
> its stability (for what its worth) and would really like to see it
> merged.
Thanks for the feedback.
From where I stand, important changes are still being installed and
discussed. Also, the discussion of whether to fork MPS has died
without any clear conclusions. Both of these are signs that the
branch is still not ready to land on master, its stability
notwithstanding.
And if we do decide to land this, we will need motivated individuals
to react to issues and fix them in a timely manner, and do other
mundane jobs that always pop up when a significant new feature lands
on master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 14:57:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> From where I stand, important changes are still being installed and
> discussed. Also, the discussion of whether to fork MPS has died
> without any clear conclusions. Both of these are signs that the
> branch is still not ready to land on master, its stability
> notwithstanding.
IIRC, the biggest con was having to keep up with upstream, which has
barely changed in years. The whole vendoring discussion began because
Emacs requires patches to MPS that aren't merged upstream because it
moves so slow (or not at all). Should we get a round of votes from
actual maintainers of feature/igc and just be done with this?
Gerd/Helmut WDYT?
> And if we do decide to land this, we will need motivated individuals
> to react to issues and fix them in a timely manner, and do other
> mundane jobs that always pop up when a significant new feature lands
> on master.
I'm unequipped to fix issues (I know as much C as our stray cat), but
what kind of mundane jobs are you looking to get help with? If its bug
triage or testing, I'm happy to apply.
Regards,
Payas
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 15:11:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 79346 <at> debbugs.gnu.org (full text, mbox):
Payas Relekar <relekarpayas <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> From where I stand, important changes are still being installed and
>> discussed. Also, the discussion of whether to fork MPS has died
>> without any clear conclusions. Both of these are signs that the
>> branch is still not ready to land on master, its stability
>> notwithstanding.
>
> IIRC, the biggest con was having to keep up with upstream, which has
> barely changed in years. The whole vendoring discussion began because
> Emacs requires patches to MPS that aren't merged upstream because it
> moves so slow (or not at all). Should we get a round of votes from
> actual maintainers of feature/igc and just be done with this?
> Gerd/Helmut WDYT?
I don't consider myself a maintainer. In fact I've said right from the
start that I don't want to maintain anything again. So I'll leave that
to others to answer.
>> And if we do decide to land this, we will need motivated individuals
>> to react to issues and fix them in a timely manner, and do other
>> mundane jobs that always pop up when a significant new feature lands
>> on master.
>
> I'm unequipped to fix issues (I know as much C as our stray cat), but
> what kind of mundane jobs are you looking to get help with? If its bug
> triage or testing, I'm happy to apply.
Eli is right, and I therefore tried to raise the question who is left to
do the maintenance, should igc land in master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79346; Package
emacs.
(Sat, 06 Sep 2025 15:31:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 79346 <at> debbugs.gnu.org (full text, mbox):
> From: Payas Relekar <relekarpayas <at> gmail.com>
> Cc: gerd.moellmann <at> gmail.com, 79346 <at> debbugs.gnu.org, eller.helmut <at> gmail.com
> Date: Sat, 06 Sep 2025 20:25:47 +0530
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > And if we do decide to land this, we will need motivated individuals
> > to react to issues and fix them in a timely manner, and do other
> > mundane jobs that always pop up when a significant new feature lands
> > on master.
>
> I'm unequipped to fix issues (I know as much C as our stray cat), but
> what kind of mundane jobs are you looking to get help with? If its bug
> triage or testing, I'm happy to apply.
It's impossible to know in advance, but helping with triage and
testing is part of that, so thanks for stepping forward.
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.