harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [jira] Created: (HARMONY-4601) [drlvm][gc_gen] Thread termination in thread.SmallStackThreadTest is terribly slow
Date Sun, 05 Aug 2007 14:05:31 GMT
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


Mime
View raw message