Sean Kelly Wrote: > 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.
If only one thread is stopped, how will a deadlock occur? If it's a deadlock due to new allocations, doesn't the current GC already handle that?
