lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rational


From: Hans Åberg
Subject: Re: Rational
Date: Wed, 23 May 2018 13:49:08 +0200

> On 23 May 2018, at 13:10, David Kastrup <address@hidden> wrote:
> 
> Hans Åberg <address@hidden> writes:
> 
>>> On 23 May 2018, at 12:20, David Kastrup <address@hidden> wrote:
>>> 
>>> ... work on "the problem" has moved beyond the stage where one can
>>> just propose a generic solution, everybody slaps his forehead and
>>> gets to work and does what it takes to do.
>> 
>> How about using what I suggested and what you touched upon in your
>> link?
> 
> Hans, with regard to the LilyPond code base you don't know what you are
> talking about.  First, LilyPond is not in a state where you can get
> serious work done with Guilev2 (memory consumption and speed are too far
> off the mark) so the Boehm GC is just a theoretical consideration for
> the bulk of the code base.  Second, its organization is such (using
> loads of STL data structures with their own allocation for storing
> structures containing only some SCM values) that the Boehm GC approach
> does not make for a good match with wholescale conservative scanning
> without employing mark hooks.

I mentioned that the GC supports traditional allocations/deallocation,

> Guilev2, including its use of the Boehm GC, is optimized for
> applications that are principally Scheme, and it works also for
> applications that are principally C++ in their approach.  Or at least
> small.  LilyPond is huge, with large resource demands, and it's sort-of
> half Scheme and half C++, both regarding its data structures as well as
> the data itself.
> 
> Guilev2 support by now is workable enough that somebody actually cluing
> himself in and working with the respective patches/branches can get a
> working setup for experimentation.  If you want to gather your own
> experience in that area and give actually qualified advice and code
> proposals, feel free to do so.

...but they must be traced so as to not end up with dead pointers.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]