
Simpler and faster GC for Go - xkarga00
https://docs.google.com/document/d/1v4Oqa0WwHunqlb8C3ObL_uNQw3DfSY-ztoA-4wWbKcg/pub
======
cottonseed
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.

~~~
kjksf
Basic mark & sweep is simple to understand and implement. See e.g.
[https://code.google.com/p/tinypy/source/browse/trunk/tinypy/...](https://code.google.com/p/tinypy/source/browse/trunk/tinypy/gc.c)
\- 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).

------
majke
> _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
In Go you avoid allocations for small values and use the stack.

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

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

------
k0t0n0
God of Speed _Dmitry Vyukov_.

~~~
andrewchambers
Dmitry is in my personal programmer hall of fame.

~~~
eloff
Ditto, the guy is a real software _engineer_.

------
signa11
debugging performance issues: [https://software.intel.com/en-
us/blogs/2014/05/10/debugging-...](https://software.intel.com/en-
us/blogs/2014/05/10/debugging-performance-issues-in-go-programs)

~~~
frik
Profiling Go Programs: [http://blog.golang.org/profiling-go-
programs](http://blog.golang.org/profiling-go-programs)

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

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

~~~
Zariel
In 1.3 the GC is concurrent mark and sweep

~~~
taeric
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?

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

~~~
stcredzero
Recounting for tenured generations would be awesome!

