Thread-Local GC as an Allocator?

[Robert Jacques]

On Thu, 06 Oct 2011 15:04:56 -0400, dsimcha <dsimcha at yahoo.com> wrote:
> == 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.
>

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.