You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Pavel Rebriy (JIRA)" <ji...@apache.org> on 2007/03/16 14:17:09 UTC
[jira] Created: (HARMONY-3413) [drlvm][thread] Re-factoring
exception safepoint callback
[drlvm][thread] Re-factoring exception safepoint callback
---------------------------------------------------------
Key: HARMONY-3413
URL: https://issues.apache.org/jira/browse/HARMONY-3413
Project: Harmony
Issue Type: Improvement
Components: DRLVM
Reporter: Pavel Rebriy
Attachments: thread_manager_safe_point_callbacks.patch
Safepoint callbacks function is used for throwing an exception for another thread. There are several safepoint callbacks: thread_stop callback is used to stop the thread, vm_shutdown callback is used to shutdown the thread and pop_frame callback is used to do PopFrame on the thread.
A thread marks itself with functions hythread_suspend_enable() and hythread_suspend_disable() in order to denote a safe region of code. A thread may also call hythread_safe_point() method to denote a selected point where safe suspension is possible. Safepoint callback function is called from suspension safe point.
The problem is not all suspension safe points are safe for exception throwing. For instance several parts of class loader or jni code expects they are working in exception free state and if hythread_suspend_disable() function raises an exception it causes an assertion. The same problems appear in interpreter.
There are 2 ways to fix the problem. The first one is to make all suspension safe points valid for exception throwing. This change is very complex, unsafe and related through all VM code. Another way is separate suspension safe point and exception valid safe point.
The suggested patch implements the second approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3413) [drlvm][thread] Re-factoring
exception safepoint callback
Posted by "weldon washburn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483417 ]
weldon washburn commented on HARMONY-3413:
------------------------------------------
it builds on linux and windows OK. It runs on winxp/32 OK. But it hangs on my 2-cpu Linux machine. A closer looks shows classloader.StressLoader is hanging. Looking at StressLoader.java, it seems there is problems with the Thread.join() api. I will investigate tomorrow.
> [drlvm][thread] Re-factoring exception safepoint callback
> ---------------------------------------------------------
>
> Key: HARMONY-3413
> URL: https://issues.apache.org/jira/browse/HARMONY-3413
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Pavel Rebriy
> Assigned To: weldon washburn
> Attachments: thread_manager_safe_point_callbacks.patch, thread_manager_safe_point_callbacks.patch
>
>
> Safepoint callbacks function is used for throwing an exception for another thread. There are several safepoint callbacks: thread_stop callback is used to stop the thread, vm_shutdown callback is used to shutdown the thread and pop_frame callback is used to do PopFrame on the thread.
> A thread marks itself with functions hythread_suspend_enable() and hythread_suspend_disable() in order to denote a safe region of code. A thread may also call hythread_safe_point() method to denote a selected point where safe suspension is possible. Safepoint callback function is called from suspension safe point.
> The problem is not all suspension safe points are safe for exception throwing. For instance several parts of class loader or jni code expects they are working in exception free state and if hythread_suspend_disable() function raises an exception it causes an assertion. The same problems appear in interpreter.
> There are 2 ways to fix the problem. The first one is to make all suspension safe points valid for exception throwing. This change is very complex, unsafe and related through all VM code. Another way is separate suspension safe point and exception valid safe point.
> The suggested patch implements the second approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3413) [drlvm][thread] Re-factoring
exception safepoint callback
Posted by "Pavel Rebriy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Rebriy updated HARMONY-3413:
----------------------------------
Attachment: thread_manager_safe_point_callbacks.patch
Updated patch after HARMONY-3288 commit.
Also comment for hythread_exception_safe_point() function is added as it was discussed on dev-list.
> [drlvm][thread] Re-factoring exception safepoint callback
> ---------------------------------------------------------
>
> Key: HARMONY-3413
> URL: https://issues.apache.org/jira/browse/HARMONY-3413
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Pavel Rebriy
> Assigned To: weldon washburn
> Attachments: thread_manager_safe_point_callbacks.patch, thread_manager_safe_point_callbacks.patch
>
>
> Safepoint callbacks function is used for throwing an exception for another thread. There are several safepoint callbacks: thread_stop callback is used to stop the thread, vm_shutdown callback is used to shutdown the thread and pop_frame callback is used to do PopFrame on the thread.
> A thread marks itself with functions hythread_suspend_enable() and hythread_suspend_disable() in order to denote a safe region of code. A thread may also call hythread_safe_point() method to denote a selected point where safe suspension is possible. Safepoint callback function is called from suspension safe point.
> The problem is not all suspension safe points are safe for exception throwing. For instance several parts of class loader or jni code expects they are working in exception free state and if hythread_suspend_disable() function raises an exception it causes an assertion. The same problems appear in interpreter.
> There are 2 ways to fix the problem. The first one is to make all suspension safe points valid for exception throwing. This change is very complex, unsafe and related through all VM code. Another way is separate suspension safe point and exception valid safe point.
> The suggested patch implements the second approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-3413) [drlvm][thread] Re-factoring
exception safepoint callback
Posted by "weldon washburn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
weldon washburn reassigned HARMONY-3413:
----------------------------------------
Assignee: weldon washburn
> [drlvm][thread] Re-factoring exception safepoint callback
> ---------------------------------------------------------
>
> Key: HARMONY-3413
> URL: https://issues.apache.org/jira/browse/HARMONY-3413
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Pavel Rebriy
> Assigned To: weldon washburn
> Attachments: thread_manager_safe_point_callbacks.patch
>
>
> Safepoint callbacks function is used for throwing an exception for another thread. There are several safepoint callbacks: thread_stop callback is used to stop the thread, vm_shutdown callback is used to shutdown the thread and pop_frame callback is used to do PopFrame on the thread.
> A thread marks itself with functions hythread_suspend_enable() and hythread_suspend_disable() in order to denote a safe region of code. A thread may also call hythread_safe_point() method to denote a selected point where safe suspension is possible. Safepoint callback function is called from suspension safe point.
> The problem is not all suspension safe points are safe for exception throwing. For instance several parts of class loader or jni code expects they are working in exception free state and if hythread_suspend_disable() function raises an exception it causes an assertion. The same problems appear in interpreter.
> There are 2 ways to fix the problem. The first one is to make all suspension safe points valid for exception throwing. This change is very complex, unsafe and related through all VM code. Another way is separate suspension safe point and exception valid safe point.
> The suggested patch implements the second approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3413) [drlvm][thread] Re-factoring
exception safepoint callback
Posted by "Pavel Rebriy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483572 ]
Pavel Rebriy commented on HARMONY-3413:
---------------------------------------
I checked classloader.StressLoader on 2-cpu Linux HT machine in all modes. It passed 100 times with the patch.
> [drlvm][thread] Re-factoring exception safepoint callback
> ---------------------------------------------------------
>
> Key: HARMONY-3413
> URL: https://issues.apache.org/jira/browse/HARMONY-3413
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Pavel Rebriy
> Assigned To: weldon washburn
> Attachments: thread_manager_safe_point_callbacks.patch, thread_manager_safe_point_callbacks.patch
>
>
> Safepoint callbacks function is used for throwing an exception for another thread. There are several safepoint callbacks: thread_stop callback is used to stop the thread, vm_shutdown callback is used to shutdown the thread and pop_frame callback is used to do PopFrame on the thread.
> A thread marks itself with functions hythread_suspend_enable() and hythread_suspend_disable() in order to denote a safe region of code. A thread may also call hythread_safe_point() method to denote a selected point where safe suspension is possible. Safepoint callback function is called from suspension safe point.
> The problem is not all suspension safe points are safe for exception throwing. For instance several parts of class loader or jni code expects they are working in exception free state and if hythread_suspend_disable() function raises an exception it causes an assertion. The same problems appear in interpreter.
> There are 2 ways to fix the problem. The first one is to make all suspension safe points valid for exception throwing. This change is very complex, unsafe and related through all VM code. Another way is separate suspension safe point and exception valid safe point.
> The suggested patch implements the second approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-3413) [drlvm][thread] Re-factoring
exception safepoint callback
Posted by "weldon washburn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
weldon washburn closed HARMONY-3413.
------------------------------------
Resolution: Fixed
build, build test passes on win32 and rhel4.0 32 w/ gcc 4.0.2
I put StressLoader.java on my local excludes list
> [drlvm][thread] Re-factoring exception safepoint callback
> ---------------------------------------------------------
>
> Key: HARMONY-3413
> URL: https://issues.apache.org/jira/browse/HARMONY-3413
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Pavel Rebriy
> Assigned To: weldon washburn
> Attachments: thread_manager_safe_point_callbacks.patch, thread_manager_safe_point_callbacks.patch
>
>
> Safepoint callbacks function is used for throwing an exception for another thread. There are several safepoint callbacks: thread_stop callback is used to stop the thread, vm_shutdown callback is used to shutdown the thread and pop_frame callback is used to do PopFrame on the thread.
> A thread marks itself with functions hythread_suspend_enable() and hythread_suspend_disable() in order to denote a safe region of code. A thread may also call hythread_safe_point() method to denote a selected point where safe suspension is possible. Safepoint callback function is called from suspension safe point.
> The problem is not all suspension safe points are safe for exception throwing. For instance several parts of class loader or jni code expects they are working in exception free state and if hythread_suspend_disable() function raises an exception it causes an assertion. The same problems appear in interpreter.
> There are 2 ways to fix the problem. The first one is to make all suspension safe points valid for exception throwing. This change is very complex, unsafe and related through all VM code. Another way is separate suspension safe point and exception valid safe point.
> The suggested patch implements the second approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3413) [drlvm][thread] Re-factoring
exception safepoint callback
Posted by "Pavel Rebriy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Rebriy updated HARMONY-3413:
----------------------------------
Attachment: thread_manager_safe_point_callbacks.patch
Here is the patch.
> [drlvm][thread] Re-factoring exception safepoint callback
> ---------------------------------------------------------
>
> Key: HARMONY-3413
> URL: https://issues.apache.org/jira/browse/HARMONY-3413
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Pavel Rebriy
> Attachments: thread_manager_safe_point_callbacks.patch
>
>
> Safepoint callbacks function is used for throwing an exception for another thread. There are several safepoint callbacks: thread_stop callback is used to stop the thread, vm_shutdown callback is used to shutdown the thread and pop_frame callback is used to do PopFrame on the thread.
> A thread marks itself with functions hythread_suspend_enable() and hythread_suspend_disable() in order to denote a safe region of code. A thread may also call hythread_safe_point() method to denote a selected point where safe suspension is possible. Safepoint callback function is called from suspension safe point.
> The problem is not all suspension safe points are safe for exception throwing. For instance several parts of class loader or jni code expects they are working in exception free state and if hythread_suspend_disable() function raises an exception it causes an assertion. The same problems appear in interpreter.
> There are 2 ways to fix the problem. The first one is to make all suspension safe points valid for exception throwing. This change is very complex, unsafe and related through all VM code. Another way is separate suspension safe point and exception valid safe point.
> The suggested patch implements the second approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.