GNU bug report logs -
#79116
31.0.50; Crash on IGC build
Previous Next
Full log
View this message in rfc822 format
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: gerd.moellmann <at> gmail.com, spd <at> toadstyle.org, pipcet <at> protonmail.com,
> 79116 <at> debbugs.gnu.org
> Date: Fri, 01 Aug 2025 09:28:07 +0200
>
> On Fri, Aug 01 2025, Eli Zaretskii wrote:
>
> >> From: Helmut Eller <eller.helmut <at> gmail.com>
> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, spd <at> toadstyle.org,
> >> pipcet <at> protonmail.com, 79116 <at> debbugs.gnu.org
> >> Date: Thu, 31 Jul 2025 18:46:49 +0200
> >>
> >> Anyway, my concern is a bit more general: I think that objects without
> >> memory barriers, (e.g. structs allocated with malloc) should be scanned
> >> as roots.
> >
> > This is very general, and in that general form quite scary. Emacs
> > allocates with malloc all over the place, and most such allocations
> > have nothing to do with Lisp objects.
>
> If there aren't any Lisp objects involved, then there is no problem.
> The problematic cases are (or could be) structs that are malloc'd and
> contain references to GC-managed objects.
What is a "GC-managed object", for this purpose? How can one
determine whether a given object is or isn't GC-managed?
> > So I hope we can have rules
> > that determine whether a given malloc'ed object needs to be scanned or
> > not, because otherwise we'll force MPS to scan too much, and lose the
> > single most important advantage it gives us: that its GC cycles are
> > fast and don't stop the application code for prolonged periods of
> > time.
>
> Yes, it would require more work during the root scanning phase.
>
> However, performance of igc is already unconvincing: throughput with the
> old GC and gc-cons-percentage = 1.0 is better than with igc.
Did you try to run interactively with gc-cons-percentage = 1.0? If
you did, can you share the experience?
> For latency, we have no benchmarks; so I'm not convinced that igc
> actually has lower latency.
My anecdotal evidence from running the igc branch is unambiguous: it
is significantly less "stuttering" than the master branch.
> Even if igc has lower latency, the current way igc triggers
> opportunistic GC doesn't work well: I've often seen "Opportunism: client
> predicts plenty of idle time, so start full collection." messages when I
> was about to type something.
So maybe some tuning is in order?
This bug report was last modified 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.