== Quote from deadalnix (deadal...@gmail.com)'s article > The problem with the global GC is that it will stop all thread during > the whole collection. Having TL GC is interesting only if you have > mostly TL garbages. > So it would become necessary to use the allocator everywhere. Which > isn't very practical either.
Right, but usually (at least in my experience) only a small portion of your code both allocates frequently and allocates at times when avoiding stopping the world is important. Therefore, with a multithreaded GC allocator you only have to worry about these issues in that small, performance-critical portion rather than this being a cross-cutting issue. This is similar to how I use RegionAllocator: I use it to get rid of a few frequent GC allocations in performance-critical parts of my code, and it works quite well. BTW, I just realized that breakage from thread-local GCs by default would leak even into SafeD. For example, they would disallow the return value of a strongly pure function from being implicitly converted to immutable as it is now, at least without some additional caveats. IMHO this is an unacceptable cross-cutting headache. If something's only benefit is performance and it causes a lot of nasty cross-cutting issues, it's almost always better for the optimization to be explicit rather than dealing with the implicit cross-cutting issues to be explicit.
