Simpler and faster GC for Go

https://docs.google.com/document/d/1v4Oqa0WwHunqlb8C3ObL_uNQw3DfSY-ztoA-4wWbKcg/pub

by xkarga00 • 12 years ago

190 33 12 years ago

docs.google.com

signa112• 12 years ago

debugging performance issues: https://software.intel.com/en-us/blogs/2014/05/10/debugging-...

frik• 12 years ago

Profiling Go Programs: http://blog.golang.org/profiling-go-programs

k0t0n0• 12 years ago

God of Speed Dmitry Vyukov.

andrewchambers• 12 years ago

Dmitry is in my personal programmer hall of fame.

eloff• 12 years ago

Ditto, the guy is a real software engineer.

shurcooL2• 12 years ago

Yeah, it was an honor to meet and talk with him in person at the last golang meetup. His incredible work is inspiring and motivating.

kyrra• 12 years ago

I don't see this on golang-dev at all. I'm interested to see the discussion around it.

cjslep• 12 years ago

The code review has discussion: https://codereview.appspot.com/106260045

hyperliner• 12 years ago

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.

shurcooL2• 12 years ago

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.

babawere• 12 years ago

Dmitry Vyukov Bug https://groups.google.com/forum/#!topic/golang-nuts/MnsJ8_F7...

majke• 12 years 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• 12 years ago

In Go you avoid allocations for small values and use the stack.

Dewie• 12 years ago

Do you do that explicitly or is at a compiler optimization?

skj• 12 years ago

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 :)

kristianp2• 12 years ago

No mention of a generational collector. The word concurrent is in there though.

Zariel• 12 years ago

In 1.3 the GC is concurrent mark and sweep

taeric• 12 years ago

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?

thescrewdriver• 12 years ago

Why mod someone down for asking about a generational GC?

kristianp2• 12 years ago

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...

cottonseed• 12 years ago

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.

papaf• 12 years ago

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.

amenghra• 12 years ago

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.

kjksf• 12 years ago

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).

signa112• 12 years ago

lua-jit reference is conspicuously missing : http://wiki.luajit.org/New-Garbage-Collector

rayiner• 12 years ago

http://www.ravenbrook.com/project/mps/

smrz• 12 years ago

Pro-tip for google docs: you can use /preview instead of /pub to get a much more readable version of the document (pagination, &c.).

Simpler and faster GC for Go

Related Stories