Re: Rational

[David Kastrup]

Hans Åberg <address@hidden> writes:

>> On 22 May 2018, at 22:53, David Kastrup <address@hidden> wrote:
>> 
>>>> This was somewhat complicated by some Midi classes being heap-allocated
>>>> and containing Rational/Moment members: those Midi classes would have to
>>>> become SCM-connected.  I did some work on that, don't remember how
>>>> complete it was.
>>> 
>>> Guile uses the Boehm GC.
>> 
>> Not Guile 1, and LilyPond will have large amounts of heap space outside
>> of Boehm's fully automated sweep areas even in Guile 2 for efficiency
>> and compatibility reasons.
>
> Something for the future then.
>
>>> I wrote a C++ wrap for that latter, too. As it turns out to be
>>> difficult to keep of pointers into the GC heap, I had to use only
>>> those that it supplies. Do you do that?
>> 
>> I don't know what "I had to use only those that it supplies" is supposed
>> to mean, so I cannot answer the question.
>
> In addition to the collected GC_malloc, there are
> GC_malloc_uncollectable and GC_free that correspond to malloc and
> free. If one uses the latter pair and have pointers into the GC heap,
> they may suddenly disappear, causing strange memory errors.

That's why we don't do that.

> In addition, beware that on some platforms, the GC must be initialized
> before the first use (like on MacOS), and if one is using global C++
> objects with heap allocations, that must occur before those being
> initialized, which is before 'main' starts.

Uhm, you _are_ aware that LilyPond has been used for large scores with
Guile data structures for 20+ years?  Don't you think people might have
noticed a problem in the mean time?  If you want to contribute useful
advice, it might be a good idea to actually look into the LilyPond code
base.  The vast majority of LilyPond's memory management in connection
with Guile is in lily/include/smobs.hh and lily/include/smobs.tcc .

-- 
David Kastrup