On 11/4/10 2:06 PM, dsimcha wrote:
== Quote from Andrei Alexandrescu ([email protected])'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?
Andrei
