Thread-Local GC as an Allocator?

[dsimcha]

== Quote from deadalnix (deadalnix at 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.