Re: Guile v2 and GC

[Han-Wen Nienhuys]

On Tue, Dec 6, 2016 at 6:54 PM, David Kastrup <address@hidden> wrote:
> Han-Wen Nienhuys <address@hidden> writes:
>
>> Hello David,
>>
>> I saw that you made (some) changes for dealing with the Guile v2
>> garbage collector. what is the overall status of this?
>
> The known problems are patched up.

so we have unknown problems? Or is it just working?

>> Have you considered defining an operator new() for the smob types? It
>> would call scm_gc_malloc. Wouldnt that take care of the whole messy
>> derived_mark business?
>
> The whole messy derived_mark business is there for a reason.  LilyPond's
> data structures are large and LilyPond fills almost all the available
> address space on 32bit systems.

It is there because GUILE 1.6 did not support anything else.

> In spite of our targeted mark passes, we still had the occasional
> "Object should be dead" message, just from conservatively marking the
> stack (and explicitly garbage collecting at a known low tide point).

Conservative garbage collection when the heap size is close to address
space is always a losing proposition, so we should not aim for it;
People that want to use a lot of RAM should buy a 64-bit system.

> And you are not going to win this by scm_gc_alloc-ing the memory of the
> smob types anyway: you need custom alloc overrides for all of the STL
> class arrays containing SCM values of some kind as well.

AFAICT There are actually very few of them.

> And of course you know that _lot_ of SCM values are not even stored
> explicitly but as structure pointers that still need ->self () calls to
> actually get a recognizable SCM value out.

well, they could be stored as SCM with conversion function.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwe