harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [jira] Created: (HARMONY-4601) [drlvm][gc_gen] Thread termination in thread.SmallStackThreadTest is terribly slow
Date Sun, 12 Aug 2007 14:53:21 GMT
On 8/12/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 8/12/07, Weldon Washburn <weldonwjw@gmail.com> 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
>

Mime
View raw message