Thread local and memory allocation

[Sean Kelly]

On Oct 3, 2011, at 3:27 PM, Jason House wrote:

> Sean Kelly Wrote:
>> There's another important issue that hasn't yet been addressed, which is that when the GC collects memory, the thread that finalizes non-shared data should be the one that created it.  So that SHARED flag should really be a thread-id of some sort.  Alternately, each thread could allocate from its own pool, with shared allocations coming from a common pool.  This would allow the lock granularity to be reduced and in some cases eliminated.
> 
> 
> Why not run the collection for a single thread in the thread being collected? It's a simple way to force where the finalizer runs. It's a big step up from stop-the world collections, but still requires pauses.

The world can't be stopped when finalizers run or the app can deadlock.  So the only correct behavior is to have the creator of a TLS block be the one to finalize it.