harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4601) [drlvm][gc_gen] Thread termination in thread.SmallStackThreadTest is terribly slow
Date Fri, 10 Aug 2007 11:35:50 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518989
] 

Xiao-Feng Li commented on HARMONY-4601:
---------------------------------------

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



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


> [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.


Mime
View raw message