On Fri, Jan 24, 2020 at 12:45 PM David Kastrup <d...@gnu.org> wrote: > >> 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.
We should be able to short circuit all of this by doing +#if GUILEV2 + +void * +operator new(std::size_t size) { + return scm_gc_malloc(size, "c++ new"); +} + +void +operator delete(void *p) { + return scm_gc_free(p, 0, "new"); +} + +#endif unfortunately, it crashes somewhere near the start of GUILE initialization. (in GUILE2 the above functions directly call GC_MALLOC, GC_FREE, so I don't understand why this would be a problem.) I am actually quite attracted to moving to GUILE 2 and using BGC. Debugging GC problems (eg. a constructor triggering GC, which then deletes the smob under construction) were one of most hairy things to get right. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen