12 ms·
Simpler and faster GC for Go
- signa11 12y agodebugging performance issues: https://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs https://software.intel.com/en-us/blogs/2014/05/10/debugging-...
- frik 12y agoProfiling Go Programs: http://blog.golang.org/profiling-go-programs http://blog.golang.org/profiling-go-programs
- k0t0n0 12y agoGod of Speed Dmitry Vyukov.
- andrewchambers 12y agoDmitry is in my personal programmer hall of fame.
- kyrra 12y agoI don't see this on golang-dev at all. I'm interested to see the discussion around it.
- cjslep 12y agoThe code review has discussion: https://codereview.appspot.com/106260045 https://codereview.appspot.com/106260045
- hyperliner 12y agoI 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.
- shurcooL 12y agoI 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.
- babawere 12y agoDmitry Vyukov Bug https://groups.google.com/forum/#!topic/golang-nuts/MnsJ8_F7ozE https://groups.google.com/forum/#!topic/golang-nuts/MnsJ8_F7...
- majke 12y ago> 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.
- mseepgood 12y agoIn Go you avoid allocations for small values and use the stack.
- deleted 12y ago[deleted]
- Dewie 12y agoDo you do that explicitly or is at a compiler optimization?
- jbooth 12y agoBoth. 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.
- skj 12y agoTo 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 :)
- eggnet 12y agoA 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.
- kristianp 12y agoNo mention of a generational collector. The word concurrent is in there though.
- Zariel 12y agoIn 1.3 the GC is concurrent mark and sweep
- taeric 12y agoI 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?
- jlouis 12y agoGenerational collectors can pick any strategy for each of their generations. What to pick depends on language, and what characteristics you want to get easily.
- stcredzero 12y agoRecounting for tenured generations would be awesome!
- thescrewdriver 12y agoWhy mod someone down for asking about a generational GC?
- kristianp 12y agoMy 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 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/fiOs3mGH1es https://groups.google.com/forum/#!topic/golang-nuts/fiOs3mGH...
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- cottonseed 12y agoSlightly 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.
- papaf 12y agoFor prototyping could you use malloc without free? I have been rolling my own GC and wish that I would have left this until later.
- amenghra 12y agoYou could try using http://www.hboehm.info/gc/ http://www.hboehm.info/gc/ An alternative is to do reference counting (in your prototyping phase), which is much easier to implement.
- kjksf 12y agoBasic mark & sweep is simple to understand and implement. See e.g. https://code.google.com/p/tinypy/source/browse/trunk/tinypy/gc.c 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).
- deleted 12y ago[deleted]
- signa11 12y agolua-jit reference is conspicuously missing : http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector
- smrz 12y agoPro-tip for google docs: you can use /preview instead of /pub to get a much more readable version of the document (pagination, &c.).