== Quote from Andrei Alexandrescu ([email protected])'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.
