Han-Wen Nienhuys <hanw...@gmail.com> writes: > On Fri, Jan 24, 2020 at 11:30 AM David Kastrup <d...@gnu.org> wrote: >> >> >> On a 64bit application, this would be somewhat more tenable, but we'd >> >> >> need to override operator new for smobs. >> >> >> >> >> >> Or do we? Maybe the heap is collected by default, and we need to >> >> >> switch >> >> >> that off? >> >> >> >> >> > What do you mean with "heap is collected"? >> >> >> >> "Collected" is probably the wrong expression. Sweeped and marked. The >> >> proposed behavior by Guile developers is not to bother with individual >> >> mark hooks and just let the whole heap be marked and sweeped. >> >> >> > >> > Did we ever try this and publish results? >> >> No. Since much of LilyPond's data containing SCM values is stored in >> STL containers, it would require serious messing with allocators to get >> there. > > Good point! And I'd agree with you, but if I look at the source code, > I can't find much STL structures that really do this. There is > Grob_array that would have to be revised, and there is a couple of > Drul_array<SCM> instances.
There are a few other structures I think. Basically one would need to go through all mark_smob routines and check for loops over arrays or other indirections. You are right that their number seems reasonably small. > There are a bunch of others (eg. in Slur_engraver), that mark into STL > structures, but they retain pointers to events (which are kept alive > through the Music structures) Stream events are not kept alive through music structures. There is a reverse mechanism that I think should actually get removed: /* ES TODO: This is a temporary fix. Stream_events should not be aware of music. */ e->set_property ("music-cause", self_scm ()); (it's in lily/music.cc). At any rate, stream events tend to be kept alive by engravers which in turn are kept alive by their contexts. Events are also kept alive as "cause" of grobs. > and grobs (which are only unprotected when they are put into the > System). -- David Kastrup