harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "cyang.cq" <cyang...@gmail.com>
Subject Re: [drlvm]program takes forever to exit when using GCV4.1 in r553700
Date Fri, 31 Aug 2007 12:41:04 GMT

Gregory Shimansky wrote:

> cyang.cq wrote:
>> It seems to be caused by commit 549899 for HAROMNY-3864. 
>> This commit introduced a global lock  to guard the methods of 
>> java.lang.ThreadGroup. And due to the global lock, adaemon thread 
>> may now block the vm_destroy process.
>> 
>>  To my knowledge, vm_destroy calls vm_shutdown_stop_java_threads
>>  to stop all the daemon threads, which registers safepoint_callback
>> (vm_shutdown_callback) for each daemon thread. At a safe point, 
>> vm_shutdown_callback calls hythread_exit to stop a thread directly. 
>> 
>> The problem is that, a daemon thread may exit spontaneously during this 
>> process. The run method of the thread returns, java.lang.Thread.detach is 
>> then called, which in turn calls ThreadGroup.remove, where the global lock 
>> is acquired. If the thread encounters a safe point, before the release of the 
>> lock, and the vm_shutdown_callback has been registered, bad thing happens: 
>> the daemon thread quits directly, the lock never gets released. The non-daemon 
>> thread who initiates the vm shutdown process, will then be blocked forever, 
>> when it calls java.lang.Thread.detach to detach itself.
>> 
>> And in the gcv4.1's case, the daemon thread makes this happen is the instance 
>> of java.lang.FinalizerThread. It is supposed to be shut down by 
>> exec_shutdown_sequence. However, exec_shutdown_sequence doesn't wait 
>> for its termination before returning.
>> 
>> Any ideas?
>> Thanks.
> 
> If it is so, then dead lock shouldn't happen only in case of GCV4.1, but 
> may happen with any other program that creates daemon threads...
> 
Yes, it's what I mean. IMHO, the probabilities of dead lock in other cases 
may be very low. 

Actually, a dead lock requires a daemon thread {calls java.lang.ThreadGroup.remove,
acquires the global lock, hits a safe point}, after the non-daemon thread calls vm_shutdown_stop_java_threads,
and before it calls java.lang.ThreadGoup.remove.


>> ----- Original Message ----- 
>> From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
>> To: <dev@harmony.apache.org>
>> Sent: Monday, August 27, 2007 10:54 AM
>> Subject: Re: [drlvm]program takes forever to exit when using GCV4.1 in r553700
>> 
>> 
>>> Looks like GCv4.1 is not covered by the daily regression testing. It
>>> should be some issues introduced in other modules. Since GCv4.1 is not
>>> actively maintained now, if possible, please try to use the default
>>> GCv5. I'd be happy to answer you questions about it.
>>>
>>> Thanks,
>>> xiaofeng
>>>
>>> On 8/26/07, cyang.cq <cyang.cq@gmail.com> wrote:
>>>> Hi, all
>>>> I checked out r553700 about one month ago. And I find that a program
>>>> sometimes takes forever to exit when using GCV4.1.
>>>>
>>>> A simple HelloWorld.java below is enough to reproduce this problem.
>>>>
>>>> public class HelloWorld{
>>>>    public static void main(String[] argv){
>>>>       System.out.println("Hello, world!");
>>>>    }
>>>> }
>>>>
>>>> java -XX:gc.dll=libgc_cc.so HelloWorld
>>>>
>>>> The "Hello, world!" can be printed out, but the program then enters dead
loop.
>>>> It seems to be blocked forever when trying to acquire the lock in
>>>> java.lang.Thread.detach();
>>>>
>>>> My configuration is:
>>>> drlvm: svn = r553700, (Aug 26 2007), Linux/ia32/gcc 3.4.3, debug/release
build
>>>> OS:    Red Hat Enterprise Linux AS release 4 (Nahant)
>>>>        Kernel 2.6.9-5.ELsmp on an i686
>>>> CPU:   4 X Intel(R) Xeon(TM) CPU 3.20GHz
>>>>
>>>>
>>>> Any suggestions?
>>>>
>>>> Thanks in advance.
>>>
>>> -- 
>>> http://xiao-feng.blogspot.com
> 
> 
> -- 
> Gregory
>
Mime
View raw message