harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [jira] Created: (HARMONY-4601) [drlvm][gc_gen] Thread termination in thread.SmallStackThreadTest is terribly slow
Date Sun, 12 Aug 2007 11:47:15 GMT
Committed. Thanks. xiaofeng

On 8/10/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> Xiao-Feng Li wrote:
> > Gregory, would you please check if we can insert a vm_thread_yield()
> > to solve the problem? This is temporary before TM has resolved the
> > issue.
> >
> > gc_gen/src/common/gc_platform.h: line 274:
> > --#define lock(x) while( !try_lock(x)){ while( x==LOCKED );}
> > ++#define lock(x) while( !try_lock(x)){            \\
> > ++                          while( x==LOCKED ){    \\
> > ++                                vm_thread_yield();   \\
> > ++                          }                                  \\
> > ++                      }
> >
> > Note, vm_thread_yield() actually calls hythread_yield(). It assumes
> > the system will schedule a next thread once invoked. If
> > hythread_yield() is not fully implemented for certain platforms, this
> > modification can't help. In that case, we write our own
> > vm_thread_yield() for all the platforms.
>
> Thank you! This works. The test on all platforms that I tried takes no
> more than 15 seconds to complete. Do you think this workaround should be
> committed? If yes, please unexclude thread.SmallStackThreadTest from VM
> acceptance tests, it is now running ok.
>
> > On 8/5/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> >> Weldon Washburn wrote:
> >>> Gegory, Xiao-Feng,
> >>> Thanks.  We will get to this problem during redesign/reimplementation.
> >>>       Weldon
> >> Ok maybe it is not really a bug, I agree. I just created it for tracking
> >> why thread.SmallStackThreadTest is excluded from the acceptance tests.
> >>
> >>> On 8/4/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >>>> This issue is not a bug. It depends on TM's design for thread
> >>>> destruction. As I understand, Weldon suggested to serialized the
> >>>> process of thread termination/creation in TM. The gc_thread_kill
> >>>> should be invoked in the serialization part. If that's true, the spin
> >>>> lock can be removed. I put the spin lock there because TM redesign is
> >>>> not finished. When it's done, we will remove the spin lock, but then
> >>>> it's TM's responsibility to invoke gc_thread_kill at proper moment.
> >>>>
> >>>> Thanks,
> >>>> xiaofeng
> >>>>
> >>>> On 8/3/07, Gregory Shimansky (JIRA) <jira@apache.org> wrote:
> >>>>> [drlvm][gc_gen] Thread termination in thread.SmallStackThreadTest
is
> >>>> terribly slow
> >>>> ----------------------------------------------------------------------------------
> >>>>>                  Key: HARMONY-4601
> >>>>>                  URL: https://issues.apache.org/jira/browse/HARMONY-4601
> >>>>>              Project: Harmony
> >>>>>           Issue Type: Bug
> >>>>>           Components: DRLVM
> >>>>>          Environment: Linux/ia32
> >>>>>             Reporter: Gregory Shimansky
> >>>>>
> >>>>>
> >>>>> The test creates a big number of threads (4000) that mostly do nothing.
> >>>> Threads are waiting and then are joined by the main thread. This mostly
> >>>> doesn't consume CPU on the machine. But then all of these threads go
through
> >>>> gc_thread_kill function. It executes thread deletion from a list under
a
> >>>> global spin-lock, so all 4000 threads are waiting on it using CPU at
the
> >>>> same time since the lock spins inside of the loop.
> >>>>> This test usually doesn't finish on linux/ia32 (for some reason
it works
> >>>> on other platforms) and times out. So I created this bug report to exclude
> >>>> it.
> >>>>> --
> >>>>> This message is automatically generated by JIRA.
> >>>>> -
> >>>>> You can reply to this email to add a comment to the issue online.
> >>>>>
> >>>>>
> >>>> --
> >>>> http://xiao-feng.blogspot.com
> >>>>
> >>>
> >>>
> >>
> >> --
> >> Gregory
> >>
> >>
> >
> >
>
>
> --
> Gregory
>
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message