Re: [feature/igc3] weak hash table lookup can return a finalized (PVEC_FREE) object

Helmut Eller <[email protected]>
Newsgroups gmane.emacs.devel
Message-ID <[email protected]>
On Sun, Aug 30 2026, Pip Cet wrote:

> Indeed, but the actual problem is slightly more complicated: in most GC
> systems, including pre-MPS Emacs, "finalization" happens when an object
> is about to be destroyed: it's the last thing to happen to an object.
>
> In MPS, however, "finalization" only means that only weak references to
> an object remain; this triggers the finalization code, but there is no
> guarantee that a new strong reference to the object hasn't been created
> by the time the finalization code is actually called (in MPS, this
> happens asynchronously, and the mechanism to do so is quite expensive).
>
> The MPS approach has its advantages (in particular, you can veto the
> actual destruction of an object in the finalizer, which is useful for
> debugging).
>
> We're currently pretending that MPS finalization is the right thing for
> Emacs finalization to use, but this isn't true: IMHO, the correct fix is
> to add last-thing-to-happen-to-an-object finalization to MPS. I have
> code somewhere to do that, synchronously, when we actually free the
> memory associated with an MPS object (instead of copying it).

What is "incorrect" with MPS finalization?  That is not synchronous or
that is inefficient?

I've been thinking about processing MPS messages more quickly.  The
basic idea is to poll the MPS message queue after mps_reserve calls
mps_ap_fill, i.e. set a flag in the slow allocation path that some
messages are queued.  Finalizers would then be called after the
mps_commit.

Would that make MPS synchronous enough?

Helmut
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.