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.
Thanks,
xiaofeng
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
>
>
--
http://xiao-feng.blogspot.com
