Re: [Gc] Two-phase finalization?

On Mon, Nov 09, 2015 at 12:20:10AM +0100, David Kastrup wrote:
> Paul Bone <[email protected]> writes:
> 
> > On Sun, Nov 08, 2015 at 12:28:14PM +0100, David Kastrup wrote:
> >> 
> >> Now the problem we encounter is that if some structure A points to B and
> >> some structure B points to A and both A and B are placed into
> >> finalization, then the finalization of A will delete the associated C++
> >> structure.  If now a mark pass is allowed through B, it will try to
> >> access the deleted C++ structure of A.
> >
> > The typical "solution" to breaking cycles for finalisation is to arrange
> > objects differently.  I use "quotes" because this is more of a work-around,
> > but I believe that it's the best solution anyone has proposed to the general
> > problem (I don't know if this will be suitable for lillypond).
> >
> >     You have:
> >
> >         A* -> B*
> >         ^     |
> >         +-----+
> >
> >     (I use * to indicate that this object has a finalize.
> >
> >
> >         A1*
> >         ^
> >         |
> >         A -> B*
> >         ^    |
> >         +----+
> >
> > Now B can be finalised first, followed by A1.  So typically you would
> > put the fields (like file descriptors) in A1 and the other fields in
> > A.  I'm trying to imagine what this means for Lillypond, maybe they're
> > glyphs for drawing notes or something...
> 
> Well, the problem with that approach is that "arrange objects
> differently" is a whole lot of work given the current amount of objects,
> and that work is not really incremental as you can expect crashes until
> finished.

I can appriciate that.  It also increases (maybe doubles) your object count
and may therefore have a performance cost.

> And that's just LilyPond: the documented semantics of the respective
> Guile hooks don't match for other applications as well.  The main coping
> strategy when brought up on the Guile developer list was an exuberant
> call for not using mark hooks at all and making all memory GC-scanned.
> However, I am less than enthused about that approach for an application
> that can eat the majority of addressable memory with large chores (given
> 32-bit executables) when basically all memory is managed with
> conservative garbage collection: I expect too many false positives then.
> It's also somewhat tricky to change the manner in which standard C++
> data structures provided by the STL libraries manage their allocations
> and deallocations.
> 
> So I prefer to stick with the same code used with Guile 1 and instead
> fix Guile 2 (or put workarounds into LilyPond to the same effect) to
> actually have the same semantics as previously regarding the "free"
> hooks.
> 
> I _think_ that the solution sketched in another mail (basically setting
> Java collection semantics for bdwgc in combination with using
> finalization for disabling the mark functionality on the destructed
> objects) should be workable.  So I hope to have self-answered my
> question.

That seems reasonable as far as I can tell.


-- 
Paul Bone