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" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> 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 <[EMAIL PROTECTED]> 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
>
