Thread-Local GC as an Allocator?

[deadalnix]

Le 06/10/2011 18:06, dsimcha a écrit :
> I've been lurking a little on the recent discussions about thread-local
> garbage collection and my general opinion is that implicitly thread-local GC
> makes it too easy to shoot oneself in the foot if using non-SafeD constructs
> like casting to shared/immutable or using std.parallelism or core.thread, and
> that SafeD concurrency is so limited that it's not reasonable to expect people
> to use only that.
>
> However, what if we kept the shared GC as the default for everything **but
> made thread-local GCs an allocator in the allocator interface that's being
> worked on**?  This probably wouldn't be hard to implement.  All you'd need is
> multiple instances of the GCX struct, one for each thread, and a way to
> register the thread-local GCs with the shared GC so that pointers from the
> thread-local GCs to shared memory get scanned properly and get rid of a little
> locking/world stopping for the thread-local instances.  Using the thread-local
> GC allocator would be an explicit assertion that you will **not** be casting
> the memory to shared/immutable and sharing it, using
> core.thread/std.parallelism, etc.  This would also keep with D's design
> philosophy that the simple, safe way should be the default but the more
> complicated, less safe way should be available for performance-critical code.
>
> Thoughts?

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.

IMO the solution should be done the other way around : if you want to do 
casting as immutable or shared, to use thoses lib, you have to specify 
it at allocation. cause you have to make sure anyway that data are 
effectively immutable/shared compliant. This cannot be done without 
knowing what you do anyway.