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
