Re:Simpler and faster GC for Go
by kristianp on Thursday July 17, 2014 @08:35AM
(#8047112)
No mention of a generational collector. The word concurrent is in there though.
[ Parent
| on HN ]
In 1.3 the GC is concurrent mark and sweep
I thought generational and mark/sweep were orthogonal. That is, can't generational still be mark and sweep? You just don't mark and sweep the entire reference set?
Generational collectors can pick any strategy for each of their generations. What to pick depends on language, and what characteristics you want to get easily.
Re:Simpler and faster GC for Go
by stcredzero on Thursday July 17, 2014 @02:13PM
(#8049179)
Recounting for tenured generations would be awesome!
Re:Simpler and faster GC for Go
by thescrewdriver on Thursday July 17, 2014 @11:43AM
(#8048136)
Why mod someone down for asking about a generational GC?
My comment was a little flip, I know, I should have asked a more friendly question. I'm wondering why it hasn't been discussed (as far as I can tell). Java has had it for ages, Ruby will have it in 2.1 and Python appears to have it as well [1]. Isn't Generational GC feasible in Go for some reason?
[1] https://docs.python.org/2/library/gc.html
Edit: Here is a discussion of gc in go. Go has only just gotten a precise collector, which is a requirement of a generational gc, to allow moving pointers.
https://groups.google.com/forum/#!topic/golang-nuts/fiOs3mGH...
Re:Simpler and faster GC for Go
by logicchains on Friday July 18, 2014 @12:04AM
(#8051603)
I've heard talk of plans for a generational, moving GC in future. It's just not something that can be implemented overnight, especially in a language with internal pointers (which Java, Ruby and Python lack).