Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of gshimansky@gmail.com
 designates 209.85.198.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=o7m0A7yCYkrPbzCQQplxE/kTW44LAAzMDabv7rIuaJF4zExqQlc3lVp5bDpUkCM+1RlDLhIKJNhJ/WIWRoCOwCfGf20H6NmABuvcQRGXtahAvDtsVbYpSEdBblYisHgPozcaUPKU2v5m92RDp6nsR5XzdXvYqp1fQv2mMj7HHTA=
Message-ID: <46BC79C5.4000503@gmail.com>
Date: Fri, 10 Aug 2007 18:44:21 +0400
From: Gregory Shimansky <gshimansky@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [jira] Created: (HARMONY-4601) [drlvm][gc_gen] Thread termination
 in thread.SmallStackThreadTest is terribly slow
References: <24718703.1186149832920.JavaMail.jira@brutus>
	 <9623c9a50708040642r66989bdby9c434206b14c5432@mail.gmail.com>
	 <4dd1f3f00708041416g13612c88hea0786f40ad36151@mail.gmail.com>
	 <46B5D92B.5050004@gmail.com>
 <9623c9a50708100433x5ddf242bq1f153e6fb7a62992@mail.gmail.com>
In-Reply-To: <9623c9a50708100433x5ddf242bq1f153e6fb7a62992@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 <gshimansky@gmail.com> 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 <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
>>
>>
> 
> 


-- 
Gregory