This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]