Committed. Thanks. xiaofeng
On 8/10/07, Gregory Shimansky <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> 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
