You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Li-Gang Wang (JIRA)" <ji...@apache.org> on 2007/04/13 10:18:15 UTC
[jira] Created: (HARMONY-3647) Issues with native threads creation
and termination
Issues with native threads creation and termination
---------------------------------------------------
Key: HARMONY-3647
URL: https://issues.apache.org/jira/browse/HARMONY-3647
Project: Harmony
Issue Type: Bug
Components: DRLVM
Environment: Win/Linux
Reporter: Li-Gang Wang
While I tested the native finref (finalizer & ref enqueue) thread implementation, I met two issues about native thread creation and termination. I have only temporary workarounds for them currently. The basic issue is how to create/terminate a native thread that has associated java.lang.Thread object.
1. On Win & Linux, jvmti.test failed occasionally
CAUSE: We couldn't attach finref threads as Java threads atomically with the according interface, attach_current_thread(). The attaching action may contend some lock with the main thread. When we ran jvmti.test, if the main thread held the lock firstly, finref threads had to run Thread class's constructor before they were associated to a Java thread structure. This would incur failure.
The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3578.
In this patch I make the main thread wait until all finref threads finish their attaching actions.
2. On Win, gc.FinAlloc test hung after it printed "PASSED" once per tens of times.
CAUSE: In vm_destroy(), finref threads are signaled to terminate and then the main thread terminates itself. But the termination of native threads is not atomic, so sometimes finref threads were not terminated properly and held a shared lock after termination. In this situation when the main thread was calling Thread.detach() method to detach itself, it could not hold the lock and was blocked.
The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3588.
In this patch, when VM signals finref threads to terminate, it will wait until the termination action finishes.
With the exploration, I suspect that current design in DRLVM might require this kind of native thread (that has associated j.l.thread object) to be treated as real Java thread, and created in Java code. That is, it doesn't allow the VM to simply create a native thread to be associated with a j.l.thread object. We need this kind of thread because we need them to run Java methods (the finalizers). I guess this should be a bug in current design, since the main thread must be created from native thread but able to run main() method of the entry class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3647) [drlvm][thread] Issues with native
threads creation and termination
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky updated HARMONY-3647:
---------------------------------------
Summary: [drlvm][thread] Issues with native threads creation and termination (was: Issues with native threads creation and termination)
Hello Li-Gang, do you think this problem still exists in the code?
> [drlvm][thread] Issues with native threads creation and termination
> -------------------------------------------------------------------
>
> Key: HARMONY-3647
> URL: https://issues.apache.org/jira/browse/HARMONY-3647
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Win/Linux
> Reporter: Li-Gang Wang
>
> While I tested the native finref (finalizer & ref enqueue) thread implementation, I met two issues about native thread creation and termination. I have only temporary workarounds for them currently. The basic issue is how to create/terminate a native thread that has associated java.lang.Thread object.
> 1. On Win & Linux, jvmti.test failed occasionally
> CAUSE: We couldn't attach finref threads as Java threads atomically with the according interface, attach_current_thread(). The attaching action may contend some lock with the main thread. When we ran jvmti.test, if the main thread held the lock firstly, finref threads had to run Thread class's constructor before they were associated to a Java thread structure. This would incur failure.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3578.
> In this patch I make the main thread wait until all finref threads finish their attaching actions.
>
> 2. On Win, gc.FinAlloc test hung after it printed "PASSED" once per tens of times.
> CAUSE: In vm_destroy(), finref threads are signaled to terminate and then the main thread terminates itself. But the termination of native threads is not atomic, so sometimes finref threads were not terminated properly and held a shared lock after termination. In this situation when the main thread was calling Thread.detach() method to detach itself, it could not hold the lock and was blocked.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3588.
> In this patch, when VM signals finref threads to terminate, it will wait until the termination action finishes.
> With the exploration, I suspect that current design in DRLVM might require this kind of native thread (that has associated j.l.thread object) to be treated as real Java thread, and created in Java code. That is, it doesn't allow the VM to simply create a native thread to be associated with a j.l.thread object. We need this kind of thread because we need them to run Java methods (the finalizers). I guess this should be a bug in current design, since the main thread must be created from native thread but able to run main() method of the entry class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-3647) [drlvm][thread] Issues with native
threads creation and termination
Posted by "weldon washburn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
weldon washburn closed HARMONY-3647.
------------------------------------
Resolution: Fixed
The Thread Lifecycle commits should have fixed this bug.
> [drlvm][thread] Issues with native threads creation and termination
> -------------------------------------------------------------------
>
> Key: HARMONY-3647
> URL: https://issues.apache.org/jira/browse/HARMONY-3647
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Win/Linux
> Reporter: Li-Gang Wang
>
> While I tested the native finref (finalizer & ref enqueue) thread implementation, I met two issues about native thread creation and termination. I have only temporary workarounds for them currently. The basic issue is how to create/terminate a native thread that has associated java.lang.Thread object.
> 1. On Win & Linux, jvmti.test failed occasionally
> CAUSE: We couldn't attach finref threads as Java threads atomically with the according interface, attach_current_thread(). The attaching action may contend some lock with the main thread. When we ran jvmti.test, if the main thread held the lock firstly, finref threads had to run Thread class's constructor before they were associated to a Java thread structure. This would incur failure.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3578.
> In this patch I make the main thread wait until all finref threads finish their attaching actions.
>
> 2. On Win, gc.FinAlloc test hung after it printed "PASSED" once per tens of times.
> CAUSE: In vm_destroy(), finref threads are signaled to terminate and then the main thread terminates itself. But the termination of native threads is not atomic, so sometimes finref threads were not terminated properly and held a shared lock after termination. In this situation when the main thread was calling Thread.detach() method to detach itself, it could not hold the lock and was blocked.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3588.
> In this patch, when VM signals finref threads to terminate, it will wait until the termination action finishes.
> With the exploration, I suspect that current design in DRLVM might require this kind of native thread (that has associated j.l.thread object) to be treated as real Java thread, and created in Java code. That is, it doesn't allow the VM to simply create a native thread to be associated with a j.l.thread object. We need this kind of thread because we need them to run Java methods (the finalizers). I guess this should be a bug in current design, since the main thread must be created from native thread but able to run main() method of the entry class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3647) [drlvm][thread] Issues with native
threads creation and termination
Posted by "Pavel Rebriy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532664 ]
Pavel Rebriy commented on HARMONY-3647:
---------------------------------------
Regarding the last comment of Xio-Feng Li the issue could be closed.
> [drlvm][thread] Issues with native threads creation and termination
> -------------------------------------------------------------------
>
> Key: HARMONY-3647
> URL: https://issues.apache.org/jira/browse/HARMONY-3647
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Win/Linux
> Reporter: Li-Gang Wang
>
> While I tested the native finref (finalizer & ref enqueue) thread implementation, I met two issues about native thread creation and termination. I have only temporary workarounds for them currently. The basic issue is how to create/terminate a native thread that has associated java.lang.Thread object.
> 1. On Win & Linux, jvmti.test failed occasionally
> CAUSE: We couldn't attach finref threads as Java threads atomically with the according interface, attach_current_thread(). The attaching action may contend some lock with the main thread. When we ran jvmti.test, if the main thread held the lock firstly, finref threads had to run Thread class's constructor before they were associated to a Java thread structure. This would incur failure.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3578.
> In this patch I make the main thread wait until all finref threads finish their attaching actions.
>
> 2. On Win, gc.FinAlloc test hung after it printed "PASSED" once per tens of times.
> CAUSE: In vm_destroy(), finref threads are signaled to terminate and then the main thread terminates itself. But the termination of native threads is not atomic, so sometimes finref threads were not terminated properly and held a shared lock after termination. In this situation when the main thread was calling Thread.detach() method to detach itself, it could not hold the lock and was blocked.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3588.
> In this patch, when VM signals finref threads to terminate, it will wait until the termination action finishes.
> With the exploration, I suspect that current design in DRLVM might require this kind of native thread (that has associated j.l.thread object) to be treated as real Java thread, and created in Java code. That is, it doesn't allow the VM to simply create a native thread to be associated with a j.l.thread object. We need this kind of thread because we need them to run Java methods (the finalizers). I guess this should be a bug in current design, since the main thread must be created from native thread but able to run main() method of the entry class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3647) [drlvm][thread] Issues with native
threads creation and termination
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489786 ]
Gregory Shimansky commented on HARMONY-3647:
--------------------------------------------
Yes, in the constructor of j.l.Thread for a native thread (the one which uses 6 arguments) context class loader is set only for the main thread to be system class loader. According to the JNI spec, and native thread attached to the VM http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/invocation.html#attach_current_thread has bootstrap class loader. So it could be that the test is just designed that it doesn't handle such situations correctly. I've seen the fix in HARMONY-3671 and I am not sure whether to consider it as a workaround...
> [drlvm][thread] Issues with native threads creation and termination
> -------------------------------------------------------------------
>
> Key: HARMONY-3647
> URL: https://issues.apache.org/jira/browse/HARMONY-3647
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Win/Linux
> Reporter: Li-Gang Wang
>
> While I tested the native finref (finalizer & ref enqueue) thread implementation, I met two issues about native thread creation and termination. I have only temporary workarounds for them currently. The basic issue is how to create/terminate a native thread that has associated java.lang.Thread object.
> 1. On Win & Linux, jvmti.test failed occasionally
> CAUSE: We couldn't attach finref threads as Java threads atomically with the according interface, attach_current_thread(). The attaching action may contend some lock with the main thread. When we ran jvmti.test, if the main thread held the lock firstly, finref threads had to run Thread class's constructor before they were associated to a Java thread structure. This would incur failure.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3578.
> In this patch I make the main thread wait until all finref threads finish their attaching actions.
>
> 2. On Win, gc.FinAlloc test hung after it printed "PASSED" once per tens of times.
> CAUSE: In vm_destroy(), finref threads are signaled to terminate and then the main thread terminates itself. But the termination of native threads is not atomic, so sometimes finref threads were not terminated properly and held a shared lock after termination. In this situation when the main thread was calling Thread.detach() method to detach itself, it could not hold the lock and was blocked.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3588.
> In this patch, when VM signals finref threads to terminate, it will wait until the termination action finishes.
> With the exploration, I suspect that current design in DRLVM might require this kind of native thread (that has associated j.l.thread object) to be treated as real Java thread, and created in Java code. That is, it doesn't allow the VM to simply create a native thread to be associated with a j.l.thread object. We need this kind of thread because we need them to run Java methods (the finalizers). I guess this should be a bug in current design, since the main thread must be created from native thread but able to run main() method of the entry class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3647) [drlvm][thread] Issues with native
threads creation and termination
Posted by "Li-Gang Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489669 ]
Li-Gang Wang commented on HARMONY-3647:
---------------------------------------
Gregory, thanks for your attention on this issue. I think the problem still exists, but I need more time to test. Currently my solution is to use the patches in the given URL links as fixes (or workrounds since I am not sure if they are the true fixes).
Actually there is one more things with native thread that has associated java.lang.Thread object, i.e., be treated as Java thread when it runs Java methods. The issue is, in current implementation when I attach a java thread object with a native thread, the j.l.Thread object constructor sets its contextClassLoader to be NULL, and this thread by default is in the same ThreadGroup with main thread.
The problem arises with test in kernel.test "java.lang.ThreadTest", which enumerates the threads in the group and accesses their contextClassloaders. Then the NULL contectClassLoader in the native threads causes failures.
This issue is addressed in JIRA H3671 by assigning a loader to the object forcefully, which I guess is only a workaround. Please have a look at it https://issues.apache.org/jira/browse/HARMONY-3671.
Thanks.
> [drlvm][thread] Issues with native threads creation and termination
> -------------------------------------------------------------------
>
> Key: HARMONY-3647
> URL: https://issues.apache.org/jira/browse/HARMONY-3647
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Win/Linux
> Reporter: Li-Gang Wang
>
> While I tested the native finref (finalizer & ref enqueue) thread implementation, I met two issues about native thread creation and termination. I have only temporary workarounds for them currently. The basic issue is how to create/terminate a native thread that has associated java.lang.Thread object.
> 1. On Win & Linux, jvmti.test failed occasionally
> CAUSE: We couldn't attach finref threads as Java threads atomically with the according interface, attach_current_thread(). The attaching action may contend some lock with the main thread. When we ran jvmti.test, if the main thread held the lock firstly, finref threads had to run Thread class's constructor before they were associated to a Java thread structure. This would incur failure.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3578.
> In this patch I make the main thread wait until all finref threads finish their attaching actions.
>
> 2. On Win, gc.FinAlloc test hung after it printed "PASSED" once per tens of times.
> CAUSE: In vm_destroy(), finref threads are signaled to terminate and then the main thread terminates itself. But the termination of native threads is not atomic, so sometimes finref threads were not terminated properly and held a shared lock after termination. In this situation when the main thread was calling Thread.detach() method to detach itself, it could not hold the lock and was blocked.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3588.
> In this patch, when VM signals finref threads to terminate, it will wait until the termination action finishes.
> With the exploration, I suspect that current design in DRLVM might require this kind of native thread (that has associated j.l.thread object) to be treated as real Java thread, and created in Java code. That is, it doesn't allow the VM to simply create a native thread to be associated with a j.l.thread object. We need this kind of thread because we need them to run Java methods (the finalizers). I guess this should be a bug in current design, since the main thread must be created from native thread but able to run main() method of the entry class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3647) [drlvm][thread] Issues with native
threads creation and termination
Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491594 ]
Xiao-Feng Li commented on HARMONY-3647:
---------------------------------------
Gregory, I think HARMONY-3671 is only a workaround. We need have better solution for native thread attaching Java thread. Let's keep this JIRA open, which points to all the three related issues. HARMONY-3578, HARMONY-3588, and HARMONY-3671.
> [drlvm][thread] Issues with native threads creation and termination
> -------------------------------------------------------------------
>
> Key: HARMONY-3647
> URL: https://issues.apache.org/jira/browse/HARMONY-3647
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Win/Linux
> Reporter: Li-Gang Wang
>
> While I tested the native finref (finalizer & ref enqueue) thread implementation, I met two issues about native thread creation and termination. I have only temporary workarounds for them currently. The basic issue is how to create/terminate a native thread that has associated java.lang.Thread object.
> 1. On Win & Linux, jvmti.test failed occasionally
> CAUSE: We couldn't attach finref threads as Java threads atomically with the according interface, attach_current_thread(). The attaching action may contend some lock with the main thread. When we ran jvmti.test, if the main thread held the lock firstly, finref threads had to run Thread class's constructor before they were associated to a Java thread structure. This would incur failure.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3578.
> In this patch I make the main thread wait until all finref threads finish their attaching actions.
>
> 2. On Win, gc.FinAlloc test hung after it printed "PASSED" once per tens of times.
> CAUSE: In vm_destroy(), finref threads are signaled to terminate and then the main thread terminates itself. But the termination of native threads is not atomic, so sometimes finref threads were not terminated properly and held a shared lock after termination. In this situation when the main thread was calling Thread.detach() method to detach itself, it could not hold the lock and was blocked.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3588.
> In this patch, when VM signals finref threads to terminate, it will wait until the termination action finishes.
> With the exploration, I suspect that current design in DRLVM might require this kind of native thread (that has associated j.l.thread object) to be treated as real Java thread, and created in Java code. That is, it doesn't allow the VM to simply create a native thread to be associated with a j.l.thread object. We need this kind of thread because we need them to run Java methods (the finalizers). I guess this should be a bug in current design, since the main thread must be created from native thread but able to run main() method of the entry class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.