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