At Thu, 12 Sep 2019 19:20:08 -0400, Philip McGrath wrote: > "Flonum unboxing: accept mismatch, for now" [...] I could imagine > that this might not be what you're looking for, since it seems like > it would be much more about creating garbage than collecting it per > se
Yes, flonum unboxing entirely a compiler project. Some things I'd like to have from the GC, but these are large projects: * GC implemented/generated in Scheme. A common problem with adding new things to the GC (including scalable object locking, ordered finalization, and vfasl saving) is repeating/copying the code that traverses objects. Each copy is a little different, and it's difficult to abstract over the variation and get good performance, especially in C. Implementing the GC itself in Scheme may be too tricky to be worthwhile, but generating a C implementation in Scheme might be the way to go. The pointer and object layouts in "cmacro.ss" is already a lot of the needed information. * Support for non-moving objects that are collected when unreferenced but not moved while referenced. Racket CS implements non-moving objects by locking objects and using a finalizer to unlock. Although I made changes to Chez Scheme so that object locking is more scalable, it would be nicer and likely perform better to have an allocation arena that is GCed but not compacted/moved. * Parallel GC * Incremental GC -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/5d7b998f.1c69fb81.8eca1.d680SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
