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>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, spd <at> toadstyle.org, pipcet <at> protonmail.com, 79116 <at> debbugs.gnu.org
Subject: bug#79116: 31.0.50; Crash on IGC build
Date: Fri, 01 Aug 2025 13:44:08 +0200

[Message part 1 (text/plain, inline)]

On Fri, Aug 01 2025, Eli Zaretskii wrote:

[...]
>> 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?

Objects that allocated on the GC heap and automatically freed are
GC-managed.

[...]
>> 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?

No.  I usually run igc with an MPS debug build; it has much longer and
noticeable GC pauses than a regular built.

However, I have a bunch of benchmarks and those are executed inside GNU
screen [*].  I don't claim that the benchmarks are good or relevant or
anything.  For the longest time I didn't even know that batch mode uses
a different gc-cons-percentage.  Doh!  The results, with all its
badness, are:

[real.svg.gz (application/gzip, attachment)]

[rss_max.svg.gz (application/gzip, attachment)]

[Message part 4 (text/plain, inline)]

The master-X versions are for gc-cons-percentage = X.  wgc is a branch
with a half finished Whipped GC.

>> 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.

Is that with gc-cons-percentage = 0.1?

>> 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?

Definitely.

Helmut

[*] https://github.com/ellerh/igc-benchmarks

Previous Next

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