[hedgehog]

Right now Go uses the naive heuristic you describe, there's no concurrent or incremental collection so no matter how long it takes to get to the GC it'll be a stop-the-world collection and potentially take a long time. I forgot to mention that besides reducing the amount of on-heap data you can also speed up collections in the current GC by lowering the GC threshold (SetGCPercent). This does come at the cost of collecting more often though so it's only really helpful if you're generating a lot of garbage on a relatively small heap. The impression I get is that for Angry Birds you would be fine with the 1.4 GC but Sim City might have some issues.

https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...

Go might eventually get a generational GC but my understanding is that that pretty much requires a copying GC and there are concerns with C interop (right now you can point to Go memory from C).

[pcwalton]

> Go might eventually get a generational GC but my understanding is that that pretty much requires a copying GC and there are concerns with C interop (right now you can point to Go memory from C).

It does. Also note that incremental GC in Go is going to have different performance characteristics than incremental GC in JavaScript, because of the fact that Go's GC has to be thread-safe.

[joelgwebber]

Indeed. I'm hopeful that the concurrent GC will get it to the point where it can do a lot better than that "10ms out of every 50" promise in 1.4. If not, then well, I guess we will have learned that Go isn't great for games after all.

/me crosses fingers.