Shared keyword and the GC?

[Michel Fortin]

On 2012-10-18 18:26:08 +0000, Sean Kelly <sean at invisibleduck.org> said:

> Well, the problem is more that a variable can be cast to shared after
> instantiation, so to allow thread-local collections we'd have to make
> cast(shared) set a flag on the memory block to indicate that it's
> shared, and vice-versa for unshared.  Then when a thread terminates, all
> blocks not flagged as shared would be finalized, leaving the shared
> blocks alone.  Then any pool from the terminated thread containing a
> shared block would have to be merged into the global heap instead of
> released to the OS.
> 
> I think we need to head in this direction anyway, because we need to
> make sure that thread-local data is finalized by its owner thread.  A
> blocks owner would be whoever allocated the block or if cast to shared
> and back to unshared, whichever thread most recently cast the block back
> to unshared.  Tracking the owner of a block gives us the shared state
> implicitly, making thread-local collections possible.  Who wants to work
> on this? :-)

All this is nice, but what is the owner thread for immutable data? 
Because immutable is always implicitly shared, all your strings and 
everything else that is immutable is thus "shared" and must be tracked 
by the global heap's collector and can never be handled by a 
thread-local collector. Even if most immutable data never leaves the 
thread it was allocated in, there's no way you can know.

I don't think per-thread GCs will work very well without support for 
immutable data, an for that you need to have a distinction between 
immutable and shared immutable (just like you have with mutable data). 
I complained about this almost three years ago when the semantics of 
shared were being defined, but it got nowhere. Quoting Walter at the 
time:

> As for a shared gc vs thread local gc, I just see an awful lot of 
strange irreproducible bugs when someone passes data from one to the 
other. I doubt it's worth it, unless it can be done with compiler 
guarantees, which seem doubtful.

I think you'll have a hard time convincing Walter it is worth changing 
the behaviour of type modifiers at this point.

Reference:
<http://lists.puremagic.com/pipermail/dmd-concurrency/2010-January/000132.html>
<http://lists.puremagic.com/pipermail/dmd-concurrency/2010-January/000146.html>

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/