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

Adam adam.mlmb at gmail.com
Wed Nov 13 01:07:30 EST 2019


That would be some Java-based Scheme e.g. SISC or Kawa, running on the
Shenandoah-OpenJDK JVM.

Many older "concurrent GC" algorithms don't scale in the respect that they
break down (as in start to have really bad STW:s) around some single-digit
number of GB of heap size, so they provide a certain offset to the STW
problem but not a remedy.

(I'd wonder what GC algo the current V8 and Firefox JSVM:s use, especially
what GC:s are there out there that are concurrent in the sense doing
collection work in a separate GC thread and then only syncing with the VM
threads for some kind of last checkpoint e.g. to checkpoint the stack
bindings as roots. In that case the only time VM code would be affected by
the GC (minus load/store barrier overhead) would be stall due to object
allocations running out of memory. I wonder does any algo like that exist?)


On Mon, 11 Nov 2019 at 23:26, Lassi Kortela <lassi at lassi.io> wrote:

> Which Scheme implementations currently have concurrent GC?
>
> If my reading of the current manual is correct, Chez doesn't have it.
>
> Ypsilon "implements 'mostly concurrent garbage collection', which is
> optimized for the multi-core CPU system". The website doesn't say which
> precise techniques it is using, but the source is available.
> <
> http://www.littlewingpinball.net/mediawiki/index.php/Ypsilon_Scheme_System
> >
>
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20191113/d01bb834/attachment.htm>


More information about the Gambit-list mailing list