Simpler and faster GC for Go(docs.google.com)
docs.google.com
Simpler and faster GC for Go
https://docs.google.com/document/d/1v4Oqa0WwHunqlb8C3ObL_uNQw3DfSY-ztoA-4wWbKcg/pub
8 comments
Slightly off topic, but is there a good (i.e., fast and easy to use) modern retargetable GC for language prototyping/implementation? I've been looking for something like this for a while, but it seems everyone rolls their own.
Basic mark & sweep is simple to understand and implement. See e.g. https://code.google.com/p/tinypy/source/browse/trunk/tinypy/... - 136 lines of C code in tinypy.
You'll find more examples if you look at other small implementations.
But you also want fast, at which point you have to accept that fast gc == complicated and tightly coupled to the implementation details (object layout, type/debug info).
There is no pluggable GC. Conservative GCs (like Boehm GC) come the closest, but they have significant drawbacks (they blindly scan all of memory and can't tell a difference between a pointer and a random number that looks like a pointer, which means scanning&marking phase take longer and they keep objects that could have been freed, which is especially a problem on 32bits, where it's more likely that a random number points inside GC-managed heap).
But you also want fast, at which point you have to accept that fast gc == complicated and tightly coupled to the implementation details (object layout, type/debug info).
There is no pluggable GC. Conservative GCs (like Boehm GC) come the closest, but they have significant drawbacks (they blindly scan all of memory and can't tell a difference between a pointer and a random number that looks like a pointer, which means scanning&marking phase take longer and they keep objects that could have been freed, which is especially a problem on 32bits, where it's more likely that a random number points inside GC-managed heap).
You could try using http://www.hboehm.info/gc/
An alternative is to do reference counting (in your prototyping phase), which is much easier to implement.
An alternative is to do reference counting (in your prototyping phase), which is much easier to implement.
[deleted]
For prototyping could you use malloc without free? I have been rolling my own GC and wish that I would have left this until later.
lua-jit reference is conspicuously missing : http://wiki.luajit.org/New-Garbage-Collector
God of Speed Dmitry Vyukov.
Dmitry is in my personal programmer hall of fame.
I don't see this on golang-dev at all. I'm interested to see the discussion around it.
The code review has discussion: https://codereview.appspot.com/106260045
I agree.
But it has always bothered me how he declares pointers! :-)
(stack[pointer] s, node[pointer] n)
Instead of
(stack [pointer]s, node [pointer]n)
Am I picky? :-)
[pointer] is the * just trying to avoid the italics conversion of HN.
But it has always bothered me how he declares pointers! :-)
(stack[pointer] s, node[pointer] n)
Instead of
(stack [pointer]s, node [pointer]n)
Am I picky? :-)
[pointer] is the * just trying to avoid the italics conversion of HN.
I remember I was going back and forth between the two over the years, and I had to keep looking up which was my "latest" preferred style.
I eventually came to the following,
(stack [pointer] s, node [pointer] n)
Since it's symmetrical, it's easy to remember.
Luckily, I've been using Go and gofmt (goimports, specifically) the last 2 years so this is no longer an issue.
I eventually came to the following,
(stack [pointer] s, node [pointer] n)
Since it's symmetrical, it's easy to remember.
Luckily, I've been using Go and gofmt (goimports, specifically) the last 2 years so this is no longer an issue.
Dmitry Vyukov Bug https://groups.google.com/forum/#!topic/golang-nuts/MnsJ8_F7...
Pro-tip for google docs: you can use /preview instead of /pub to get a much more readable version of the document (pagination, &c.).
[deleted]
[deleted]
debugging performance issues: https://software.intel.com/en-us/blogs/2014/05/10/debugging-...
Profiling Go Programs: http://blog.golang.org/profiling-go-programs
> GC scanning and marking phase is 10-20% faster for programs with large number of small objects.
Which is most programs. Hurray, changes in good direction.
Which is most programs. Hurray, changes in good direction.
In Go you avoid allocations for small values and use the stack.
To be fair, we do that to avoid GC slowdown issues. If the GC improves to the point where that's no longer an issue, we don't have to do that anymore :)
A 30% improvement is nice but nowhere near enough to change programming best practices in go.
A significant algorithmic change in the GC, like a generational compacting GC or something along those lines, would have to be made to alter go programming strategies.
A significant algorithmic change in the GC, like a generational compacting GC or something along those lines, would have to be made to alter go programming strategies.
[deleted]
Do you do that explicitly or is at a compiler optimization?
Both. If you deal with a value type (struct or primitive) and never take the address of it, it can't exist anywhere besides the current stack, value types are copied if you return it out of a function or call another function with it.
For reference types, they do have escape analysis, not sure how one would compare it to another language.
For reference types, they do have escape analysis, not sure how one would compare it to another language.
No mention of a generational collector. The word concurrent is in there though.
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.
Recounting for tenured generations would be awesome!
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...
[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...
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).
FYI: Ruby 2.1 has been released for some time now.