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)


Jim Blandy <jimb@savonarola.red-bean.com> writes:

> But his GC is trying to solve a harder problem than ours: he's trying
> to replace malloc in GC-ignorant programs.

That is *one* of the intended uses of the Boehm gc.

> - 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.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

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