Ruling out arbitrary cost copy construction?

[Sean Kelly]

Andrei Alexandrescu Wrote:

> On 11/4/10 2:06 PM, dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
> >> 2. Each destructor should be called in the thread that created the object.
> >> The second solution is quite attractive. It can be implemented by
> >> associating each thread with a worklist - a list of objects to destroy.
> >> The GC can run in any thread but it will not call destructors. Instead,
> >> it adds objects to be destroyed to the threads that created them (this
> >> means we need to add a field to each object with the thread ID of the
> >> creating thread). When client code calls new, the allocation routine
> >> will first inspect the worklist and call the destructors if needed.
> >> I think this can be made to work and has good properties, although a
> >> fair amount of details need to be figured out. Please share any thoughts
> >> you may have.
> >> Andrei
> >
> > Interesting, though I feel like the baseline cruft for Object is getting a little
> > big.  I think we could store the thread ID and the monitor object in the same
> > memory.  If a class is being synchronized on, then it's shared rather than being
> > owned by a single thread.  Therefore, at an offset of 1, a class either has a
> > pointer to a monitor (if it's shared, and therefore can be destroyed in any
> > thread) or a thread ID (if it's unshared).  To tell them apart, just see if the
> > classinfo pointer points to a Monitor or a Thread.
> 
> Yah, my thoughts exactly. My feeling is that this is one of those areas 
> where it's difficult to find a solution that's at the same time simple 
> and good.
> 
> Sean, any thoughts?

Right now monitors are structs, typically allocated with malloc.  I think they could be transformed to classes in conjunction with some porting of old runtime C code to D, but that's more than a few line fix.  It also doesn't address the issue of dynamically allocated structs, but perhaps those will be ruled as not-to-be-finalized-by-the-GC?  An alternative would be for the GC to store this info in a lookup table of some sort, though I do like the dual use of the monitor slot in objects.