Re: Rational

[David Kastrup]

Hans Åberg <address@hidden> writes:

>> On 22 May 2018, at 23:28, David Kastrup <address@hidden> wrote:
>> 
>> 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 .
>
> So you don't know anything about the Boehm GC?

Is there a point to this silliness?

<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19883>

Apparently I got to know enough to distill a test case showing that
Guilev2's type system was critically affected by a bug in the Boehm GC's
use of finalizers, leading to workarounds first in the LilyPond code
base and later on in Guile proper.

I appreciate that you are trying to be helpful but the state of my
involvement with Guilev2 (and consequently also the Boehm GC) is such
that one needs to have been living under the proverbial rock regarding
the developer mailing list traffic to assume that I have no idea about
the details of the memory management components of the Guilev2
transition.

For better or worse, we have moved seriously beyond the point where
smart off-hand observations are going to be the saving grace of the day.
Really, you'll need to invest more than that if you want to make a
difference.

-- 
David Kastrup