On Thu, 06 Oct 2011 15:04:56 -0400, dsimcha <dsim...@yahoo.com> wrote:
== 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.
Well, aren't heap allocations from strongly pure arrays eventually going to be
deep-duped anyways? One of the major GC advantages of strongly pure functions
is that you don't have to mark-sweep everything it allocates: anything not
pointed by the return value can be straight forwardly trashed.
