Ruling out arbitrary cost copy construction?

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
> Thanks to all for a very illuminating discussion. The dialog revealed
> that the topic of cheap copy construction is oddly linked with the topic
> of garbage collection: garbage collection calls destructors concurrently
> with other code, which means reference count code must be interlocked,
> which makes it not-so-cheap.
> This is only a manifestation of a deeper problem: destructors can
> execute arbitrary code, and, if ran in an arbitrary thread, can cause
> all sorts of deadlocks and essentially render "shared" inoperant.
> Walter and I discussed two possibilities this morning:
> 1. Never call class destructors (or never call them if more than one
> thread is running)
> 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.