On 8/12/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > On 8/12/07, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > Xiao Feng, > > From below you said, > > > > > > But we actually found neither Assumption 1 nor 2 was guaranteed to be > > > hold true, so we introduced spinlock for temporary solution, hoping to > > > remove spinlock for the list access finally. > > > > > The above is curious. I tracked through the Thread Manager code and > > see that hythread_global_lock(NULL); is indeed held during parts of > > thread create, kill and stop-the-world GC enumeration. Maybe somehow > > the thread list is being accessed outside of the global_lock?? > > > > Assumption 1) and 2) make complete sense to me. But is it really true > > that both Assumption 1) and 2) have been violated? > > Yes, it was. I has checked it for a long time. Probably the > global_lock was added then after. If the global_lock can guarantee the > two assumptions, it can be verified by removing the spin locks.
If the overall performance is acceptable and there are no hangs/deadlocks associated with "lock(gc->mutator_list_lock);" then let's leave things as they are now. This will allow us some design and implementation freedom in the Thread Manager code. > > > I assume the GC is not holding a privately maintained list of > > enumerable java threads. Is this correct? > > No, the mutator list is privately maintained by GC. It avoids GC/VM > interactions to access the thread list in VM. If the assumptions are > true, to have a private list is a good optimization, in my opinion. > Since GC needs to maintain mutator-specific data structure for thread > local allocation, this list is sort of necessary. I never really thought about this. Of course the GC needs to have its own internal lists of live java threads. We need to be careful about the protocol between the GC and Thread Manager to make sure both see the same list of non-NEW and non-TERMINATED (aka live) java threads at all times. > > Thanks, > xiaofeng >
