Ruling out arbitrary cost copy construction?

[Sean Kelly]

Steven Schveighoffer Wrote:

> On Thu, 04 Nov 2010 18:35:51 -0400, Sean Kelly <sean at invisibleduck.org>  
> wrote:
> 
> > Steven Schveighoffer Wrote:
> >>
> >> What if a thread no longer exists?  Would there be a way to mark such
> >> dtors that need this feature?  I don't know, because it seems to me  
> >> like a
> >> lot of band-aiding for something that is infrequently used (I've gotten
> >> along fine in D without reference counting for as long as I've used it).
> >
> > If a thread no longer exists then it doesn't matter who calls the  
> > finalizers so long as they aren't finalized concurrently by more than  
> > one thread.  To simplify things, the thread could notify the GC on  
> > termination so it could eagerly do whatever maintenance it wants to.
> 
> Right, but in Andrei's idea (from what I can tell), the GC does not call  
> destructors, it just adds to thread-specific worklists.
> 
> But I think it's a non-issue.  Just stick it on the worklist of the  
> current thread, since the dead thread doesn't care anymore.  I'm assuming  
> the current thread's worklist is cleaned at the end of the GC cycle.


The beginning, before a collection is triggered.  It would be like a mini-collection.


> > The GC would probably be the best place to track which thread owned what  
> > object so it would probably be the best place to store the work-list as  
> > well.  This is somewhat similar to how HOARD handles freed memory, so  
> > there is certainly a precedent for an allocator taking care of this sort  
> > of thing.
> 
> It could be in the Thread object, or in a thread's TLS.  I feel the Thread  
> object is much easier to get at from another thread than another thread's  
> TLS, or is there an easy way to do this?
> 
> Hm... I just had a thought -- what is going to be the performance of  
> continuously looking up the right worklist to add to based on the thread  
> ID?

That's one reason I thought the work list should be in the GC.  It could store the per-block field in a parallel block of memory to each page, and this would be an index into an array.  When a thread terminates the work list could be processed and released for re-use.  No opaque function calls for lookup or anything like that.

> > I'm still inclined to say that the GC should take care of the grunt work  
> > though, unless someone wants to argue that owner thread ID of every  
> > object should be stored in a new hidden field in the object itself.
> 
> I think that is what Andrei is suggesting.  Unless we want to change the  
> language to be able to flag reference counted types so the GC can see that.

I'm just not sure it's worth changing the ABI for this.  Particularly when the "thread ID" is implementation-defined.

> Can we encapsulate all this function into a member?  So for instance you  
> just add a RefCount type in your struct, and it contains the code to deal  
> with this problem?

Probably.