This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: GUILE's GC - why we struggling to solve already solved problems ? (was Re: finding the top of the stack in linux)
That sounds like what I was looking for.
I have a hard time believing that the Boehm GC can perform as well as
Guile's GC, since it has (it seems) so little specific information
about the Guile heap, which has a lot of regularities which (again, it
seems to me) ought to help one write a faster GC. But my specific
objects are pretty much exhausted at this point. It's time to
experiment.
> > - We can require that they use a software write barrier. Software write
> > barriers are much more efficient than Unix VM barriers, according to
> > all the papers I've read. But for Boehm, it's not an option.
>
> I believe it is:
>
> Incremental and generational collection is effective in reducing
> pause times only if the collector has some way to tell which
> objects or pages have been recently modified. The collector uses
> two sources of information:
>
> 1. Information provided by the VM system. ...
>
> 2. Information supplied by the programmer. We define "stubborn"
> objects to be objects that are rarely changed. Such an object can
> be allocated (and enabled for writing) with GC_malloc_stubborn.
> Once it has been initialized, the collector should be informed
> with a call to GC_end_stubborn_change. Subsequent writes that
> store pointers into the object must be preceded by a call to
> GC_change_stubborn.
>
> This mechanism performs best for objects that are written only for
> initialization, and such that only one stubborn object is writable
> at once. It is typically not worth using for short-lived objects.
> Stubborn objects are treated less efficiently than pointerfree
> (atomic) objects.