3 ms·
He's (a) too dismissive of the huge throughput benefits of generational GC; The ObjectStudio VM engineers used to lament over the advantage the VisualWorks GC
by stcredzero 8y ago
He's (a) too dismissive of the huge throughput benefits of generational GC;
The ObjectStudio VM engineers used to lament over the advantage the VisualWorks GC had: VisualWorks only had to garbage collect one thread. ObjectStudio had gone multi-threaded, and to stop the world, the VM had to signal all of the threads, and wait for all of them to come to an inactive state. The more parallelism in the form of more machine threads, the higher this penalty is likely to be.
treating "request-oriented" GC as something other than generational GC, when it's really just a somewhat limited form of generational GC.
Isn't it more accurate to say that it's a simpler way of getting to use low cost bump allocation and very low cost deallocation? Even generational GC needs some knowledge and skill from programmers to achieve the highest level of efficiency. (Or even some modicum of knowledge to keep it from failing.) The golang request-oriented hypothesis just moves the cost-benefit tradeoff knobs. To get beyond middling performance, you still have to profile and optimize either way. Profiling allocation is usually straightforward.
- pcwalton 8y ago> The ObjectStudio VM engineers used to lament over the advantage the VisualWorks GC had: VisualWorks only had to garbage collect one thread. I'm not sure what this is trying to imply. Modern generational GCs use TLABs to solve this exact problem.
- stcredzero 8y ago> TLAB Thread Local Allocation Buffer. Cool. Doesn't the stack in golang serve somewhat the same purpose? I've sometimes wondered about golang going the direction of Erlang, with multiple independent GCs. (Not per goroutine. It would have to be per "Actor" which I find myself implementing again and again in golang.) Modern generational GCs use TLABs to solve this exact problem. So that solves the problem on allocation, while the generational hypothesis reduces the frequency of stop the world. Generalizing in this fashion, I don't see why generational GC is inevitably necessary. With golang, the stack provides cheap allocation to local threads, even with concurrency, and throughput isn't as big a deal, with a bit more work needed by the programmer for optimization. (But perhaps my view would change with access to more data or with more experience.)
- littlestymaar 8y ago> I don't see why generational GC is inevitably necessary But remind that almost everybody having to implement a GC (but the Go team) thinks otherwise. Do you believe you know more than langage runtime engineers ? Because that's Go folks seams to believe, and that's anoyingly arrogant…
- foldr 8y agoThe fact that Go has acceptable GC performance surely shows that it's not inevitably necessary.