4 ms·
> The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements. It is de
by enneff 14y ago
> The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements.
It is definitely true that the JVM had been thoroughly road tested compared to Go, but your conclusion is unsound. Go was designed to specifically avoid this pitfall.
- CJefferson 14y agoReally? I remember reading all kinds of problems when trying to run go on 32-bit machines, like: http://news.ycombinator.com/item?id=3805302 http://news.ycombinator.com/item?id=3805302
- codygman 14y agoYou are correct, but the none of those problems happened on 64 bit machines which I find to be more prevalent these days.
- CJefferson 14y agoStill, this story seems much more crazy than any other gc issue I have ever heard of with the jvm.
- enneff 14y agoThe 32-bit GC issue is an unfortunate shortcoming of the GC implementation, which will be resolved in Go 1.1 early this year. The issue was merely an artifact of dead simple conservative GC implementation. OTOH, the memory model of the JVM is intractably linked with its design. Software that runs on the JVM must generate garbage, and so the JVM must include a highly sophisticated GC. Remember how appallingly bad the JVM was when it was just a few years old? It didn't come close to where we are with Go today. We have only scratched the surface with GC (and other optimizations) for Go.
- jlouis 14y agoSorry, but I am not sure I understand which pitfall you refer to here? Can you elaborate?