GNU bug report logs - #77338
feature/igc: when can we run finalizers?

Previous Next

To reply to this bug, email your comments to 77338 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: feature/igc: when can we run finalizers?
Date: Fri, 28 Mar 2025 15:03:39 +0000

In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77325#14, Daniel
writes:

> IGC does GC all the time --- but it's not observable because we pump
> messages from the GC only at dedicated points and run GC hooks only in
> response to these messages. however, notice that on the IGC branch that
> we pump GC messages, including finalizer callbacks, on the allocation
> path for, e.g. various pseudovectors.  That'll cause Lisp to run where
> it wouldn't have before. Is that going to be a problem?  ISTM we can
> either pump messages in maybe_quit() or just rely on igc_on_idle().

That is indeed a bug and one which actually caused a crash for me.  It's
related to changing the new marker structure to use finalizers rather
than attempting to unchain markers in a finalizer rather than doing so
in the fix method.

The problem is that bignums need to be eagerly finalized or we'll run
out of memory running the pidigits benchmark.  I'm not sure whether
there are other objects which also allocate memory that needs to be
freed for correctness.

Another problem is that I'm not sure who uses Lisp finalizers and
whether the slightly weaker semantics of MPS finalizers suffice for
them: IIUC, MPS queues a finalizer when it discovers an object is no
longer reachable except through weak references, and doesn't unqueue it
even if a weak reference is strengthened again (maphash can do this).

So a finalizer can run for an object that actually survived.  Is that
ever acceptable?  Can we prevent it?

Previous Next

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