You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2007/08/27 04:54:38 UTC
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 <cy...@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
Re: [drlvm]program takes forever to exit when using GCV4.1 in r553700
Posted by "cyang.cq" <cy...@gmail.com>.
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" <xi...@gmail.com>
>> To: <de...@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 <cy...@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
>
Re: [drlvm]program takes forever to exit when using GCV4.1 in r553700
Posted by Gregory Shimansky <gs...@gmail.com>.
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...
> ----- Original Message -----
> From: "Xiao-Feng Li" <xi...@gmail.com>
> To: <de...@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 <cy...@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
Re: [drlvm]program takes forever to exit when using GCV4.1 in r553700
Posted by "cyang.cq" <cy...@gmail.com>.
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.
----- Original Message -----
From: "Xiao-Feng Li" <xi...@gmail.com>
To: <de...@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 <cy...@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