emacs-devel
[Top][All Lists]
Advanced

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

Re: Some experience with the igc branch


From: Eli Zaretskii
Subject: Re: Some experience with the igc branch
Date: Sat, 28 Dec 2024 16:08:31 +0200

> Date: Sat, 28 Dec 2024 13:12:18 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: gerd.moellmann@gmail.com, stefankangas@gmail.com, ofv@wanadoo.es, 
> emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> Date: Fri, 27 Dec 2024 17:26:04 +0000
> >> From: Pip Cet <pipcet@protonmail.com>
> >> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>, stefankangas@gmail.com, 
> >> ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, 
> >> acorallo@gnu.org
> >>
> >> "Eli Zaretskii" <eliz@gnu.org> writes:
> >>
> >> >   - Concurrent.  The GC runs in its own thread.  There are no explicit
> >> >     calls to start GC, and Emacs doesn't have to wait for the GC to
> >> >     complete.
> >> >
> >> > Pip says this is not true?
> >>
> >> I'm a bit confused.  Right now, on scratch/igc, on GNU/Linux, for Emacs
> >> in batch mode, it isn't technically true.
> >
> > Then how do you explain the fact that, when igc does GC (as evidenced
> > by the echo-area messages if you enable garbage-collection-messages),
> > Emacs is not stopped, as it happens with the old GC?  If GC is done on
> > the main thread, it means the main thread should stop while GC is in
> > progress, and yet I don't see it stopping.  What did I miss?
> 
> I have no idea how you "see it stopping".

Like we always do: try scrolling through xdisp.c, and you will see
Emacs stop from time to time for a split-second, then resume
scrolling.  If you set garbage-collection-messages non-nil, you will
see a GC message when it stops for that time.

With igc, the scrolling is continuous, at least in my perception.

Similar "stuttering" happens in other repeated operations that have
clear visible effects.

> Incremental GC happens in increments, which take less time
> individually than a full GC cycle would, so interactions are
> smoother.  Separate threads are certainly not required for that
> (neither is incremental GC, in all cases; mark-and-sweep collectors
> can be interrupted, discarding the mark bits).

Maybe you are right.  But the difference should be quite significant
to explain what I see.



reply via email to

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