[gambit-list] Real-time or generational gc?

Dimitris Vyzovitis vyzo at hackzen.org
Sat Nov 9 10:02:09 EST 2019


Thanks Marc!

Just to be clear, the pause times are not currently causing an issue for me.

There is a gerbil however who has been investigating pause times and found
a pathological program that allocates u8vectors and stuffs them into a hash
table. In that case, there is an accumulation of memory, leading to pause
times of 500-600ms, while racket averages 20ms (with a peak of about 170ms)
on the equivalent program. This is clearly an artifact of generational gc,
but it always vexes me when racket seemingly does better at something :p

-- vyzo


On Sat, Nov 9, 2019 at 4:33 PM Marc Feeley <feeley at iro.umontreal.ca> wrote:

> > On Nov 9, 2019, at 8:36 AM, Dimitris Vyzovitis <vyzo at hackzen.org> wrote:
> >
> > Are there any plans to implement a real-time or a generational gc in
> gambit?
> > It would be nice to get thoz pause times down!
> >
> > -- vyzo
>
> I’m curious to know the context where the pause times are causing an
> issue.  Can you give more context?  What is the app, and what are the pause
> times like?  You can get GC traces by using the -:d2 runtime option.
>
> Did you try the parallel garbage collector?  That may help with pause
> times.  It is sufficient to configure with --enable-multiple-threaded-vms
> to activate it.
>
> There are no immediate plans to work on generational or real-time GC,
> although I have a prospective student that is thinking about improving the
> GC.
>
> The current object representation has been designed to accomodate handles
> and generation number information in the header, which would be useful to
> implement a generational GC.
>
> One of the biggest issues to solve is the handling of Scheme objects by C
> code (including the FFI).  The problem is that, with a generational GC,
> every assignment of a Scheme object reference includes an allocation of
> sorts because any inverse reference (old generation object pointing to an
> object in a younger generation) created by the assignment needs to be
> registered in a table of inverse references.  So with a generational GC,
> every assignment of a Scheme object reference may actually trigger a
> garbage collection.  So C code handling Scheme objects must take extra
> precautions to ensure that after an assignment the object assigned to
> hasn’t been moved by the GC (currently that is impossible, even with
> multiple threaded VMs, because garbage collections are synchronous across
> all the processors)  The change would entail a considerable amount of work
> to review the parts of the runtime system written in C, and cause a
> backward incompatible change for current user code.  A can of worms that is
> best kept closed until there is a good motivation (both technical and in
> the Gambit community) to work on that.
>
> Marc
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20191109/b1cf57bb/attachment.htm>


More information about the Gambit-list mailing list