<div dir="ltr"><div dir="ltr"><div>Thanks Marc!</div><div><br></div><div>Just to be clear, the pause times are not currently causing an issue for me.</div><div><br></div><div>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<br></div><div><br></div><div>-- vyzo</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 9, 2019 at 4:33 PM Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On Nov 9, 2019, at 8:36 AM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org" target="_blank">vyzo@hackzen.org</a>> wrote:<br>
> <br>
> Are there any plans to implement a real-time or a generational gc in gambit?<br>
> It would be nice to get thoz pause times down!<br>
> <br>
> -- vyzo<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Marc<br>
<br>
<br>
</blockquote></div></div>