4 ms·
Go's "request oriented collector" proposal is a generational GC, and Ruby has had a generational GC since 2.1. Generational GC is about minimizing GC overhead b
by jashmatthews 8y ago
Go's "request oriented collector" proposal is a generational GC, and Ruby has had a generational GC since 2.1. Generational GC is about minimizing GC overhead by avoiding re-marking the entire heap.
OOBC is very different. It's trading an increased overhead from collecting more often than necessary for a lower latency experienced by users.
- twic 8y agoThe request-oriented collector is not just a generational GC by another name. The key point: This write barrier design allows ROC to efficiently reclaim unpublished objects when a goroutine exits simply by resetting the current sweep pointer back to the initial sweep pointer. If you use a disposable goroutine for a task, then when it exits, any memory it allocated but did not publish to other goroutines can be reclaimed without doing any further work. It's very much based on the idea that if you can put off collection to the end of a task, you can do it more efficiently, like OOBGC, but approached from a different angle. I have no idea how well it actually works in practice. I've wanted something similar in Java for years, though!
- jashmatthews 8y agoThis is still generational GC but with a young generation heap per coroutine. I've been working on multi-heap GC for MRI Ruby. Compared to traditional concurrent generational GC, skipping the marking when a coroutine terminates is not really an advantage because there will be no live objects to mark and marking would immediately terminate anyway. After that, you just reset the nursery pointer and you're done.