You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Chengrong Shi (JIRA)" <ji...@apache.org> on 2007/10/19 08:53:50 UTC

[jira] Created: (HARMONY-4972) unbalanced monenter/monexit pair in HIR

unbalanced monenter/monexit  pair in HIR
----------------------------------------

                 Key: HARMONY-4972
                 URL: https://issues.apache.org/jira/browse/HARMONY-4972
             Project: Harmony
          Issue Type: Task
          Components: DRLVM
         Environment: compiled by JDK5.0
            Reporter: Chengrong Shi
            Priority: Critical


    I found a puzzling case of the HIR. The attachment is the picture of the HIR. In this pictrue, the control flows along the 2 in-edges of Node 98(the node whose id is 98) seem to have different lock state.The control flow from the left in-edge is unlocked at the end of Node 102, but the control flow from the right in-edge is not unlocked. Because if exception has been thrown then the last monexit of Node 102 will not been executed.
    Is this case legal? Or I missed something else?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HARMONY-4972) [drlvm][jit]unbalanced monenter/monexit pair in HIR

Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Fursov updated HARMONY-4972:
------------------------------------

                Priority: Minor  (was: Major)
    Estimated Complexity: Moderate  (was: Unknown)

> [drlvm][jit]unbalanced monenter/monexit  pair in HIR
> ----------------------------------------------------
>
>                 Key: HARMONY-4972
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4972
>             Project: Harmony
>          Issue Type: Task
>          Components: DRLVM
>         Environment: compiled by JDK5.0
>            Reporter: Chengrong Shi
>            Assignee: Mikhail Fursov
>            Priority: Minor
>         Attachments: test.rar
>
>
>     I found a puzzling case of the HIR. The attachment is the picture of the HIR. In this pictrue, the control flows along the 2 in-edges of Node 98(the node whose id is 98) seem to have different lock state.The control flow from the left in-edge is unlocked at the end of Node 102, but the control flow from the right in-edge is not unlocked. Because if exception has been thrown then the last monexit of Node 102 will not been executed.
>     Is this case legal? Or I missed something else?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HARMONY-4972) [drlvm][jitrino]unbalanced monenter/monexit pair in HIR

Posted by "Chengrong Shi (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chengrong Shi updated HARMONY-4972:
-----------------------------------

    Summary: [drlvm][jitrino]unbalanced monenter/monexit  pair in HIR  (was: unbalanced monenter/monexit  pair in HIR)

> [drlvm][jitrino]unbalanced monenter/monexit  pair in HIR
> --------------------------------------------------------
>
>                 Key: HARMONY-4972
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4972
>             Project: Harmony
>          Issue Type: Task
>          Components: DRLVM
>         Environment: compiled by JDK5.0
>            Reporter: Chengrong Shi
>            Priority: Critical
>         Attachments: test.rar
>
>
>     I found a puzzling case of the HIR. The attachment is the picture of the HIR. In this pictrue, the control flows along the 2 in-edges of Node 98(the node whose id is 98) seem to have different lock state.The control flow from the left in-edge is unlocked at the end of Node 102, but the control flow from the right in-edge is not unlocked. Because if exception has been thrown then the last monexit of Node 102 will not been executed.
>     Is this case legal? Or I missed something else?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (HARMONY-4972) [drlvm][jit]unbalanced monenter/monexit pair in HIR

Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Fursov reassigned HARMONY-4972:
---------------------------------------

    Assignee: Mikhail Fursov

> [drlvm][jit]unbalanced monenter/monexit  pair in HIR
> ----------------------------------------------------
>
>                 Key: HARMONY-4972
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4972
>             Project: Harmony
>          Issue Type: Task
>          Components: DRLVM
>         Environment: compiled by JDK5.0
>            Reporter: Chengrong Shi
>            Assignee: Mikhail Fursov
>         Attachments: test.rar
>
>
>     I found a puzzling case of the HIR. The attachment is the picture of the HIR. In this pictrue, the control flows along the 2 in-edges of Node 98(the node whose id is 98) seem to have different lock state.The control flow from the left in-edge is unlocked at the end of Node 102, but the control flow from the right in-edge is not unlocked. Because if exception has been thrown then the last monexit of Node 102 will not been executed.
>     Is this case legal? Or I missed something else?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HARMONY-4972) [drlvm][jitrino]unbalanced monenter/monexit pair in HIR

Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Ellison updated HARMONY-4972:
---------------------------------

    Priority: Major  (was: Critical)

Reducing the priority as per Pavel's suggestion.


> [drlvm][jitrino]unbalanced monenter/monexit  pair in HIR
> --------------------------------------------------------
>
>                 Key: HARMONY-4972
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4972
>             Project: Harmony
>          Issue Type: Task
>          Components: DRLVM
>         Environment: compiled by JDK5.0
>            Reporter: Chengrong Shi
>         Attachments: test.rar
>
>
>     I found a puzzling case of the HIR. The attachment is the picture of the HIR. In this pictrue, the control flows along the 2 in-edges of Node 98(the node whose id is 98) seem to have different lock state.The control flow from the left in-edge is unlocked at the end of Node 102, but the control flow from the right in-edge is not unlocked. Because if exception has been thrown then the last monexit of Node 102 will not been executed.
>     Is this case legal? Or I missed something else?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (HARMONY-4972) [drlvm][jitrino]unbalanced monenter/monexit pair in HIR

Posted by "Pavel Ozhdikhin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HARMONY-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538404 ] 

Pavel Ozhdikhin commented on HARMONY-4972:
------------------------------------------

In the attached example, a synchronized method has been inlined and JIT inserted a monexit instruction with re-throw of possible exception thrown in the inlined method (nodes 102 and 103). JIT does not generate a monitor exit loop in this case like javac does for synchronized statements. When a synchronized method is called and monitor has been entered the monitor object is valid. Unless it is possible to write a malicious code on jasm which will invalidate monitor object before node 102, the example is generally harmless.

This case requires additional investigation. Until there is no real test showing the problem, I suggest to lower priority of this bug.


> [drlvm][jitrino]unbalanced monenter/monexit  pair in HIR
> --------------------------------------------------------
>
>                 Key: HARMONY-4972
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4972
>             Project: Harmony
>          Issue Type: Task
>          Components: DRLVM
>         Environment: compiled by JDK5.0
>            Reporter: Chengrong Shi
>            Priority: Critical
>         Attachments: test.rar
>
>
>     I found a puzzling case of the HIR. The attachment is the picture of the HIR. In this pictrue, the control flows along the 2 in-edges of Node 98(the node whose id is 98) seem to have different lock state.The control flow from the left in-edge is unlocked at the end of Node 102, but the control flow from the right in-edge is not unlocked. Because if exception has been thrown then the last monexit of Node 102 will not been executed.
>     Is this case legal? Or I missed something else?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HARMONY-4972) unbalanced monenter/monexit pair in HIR

Posted by "Chengrong Shi (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chengrong Shi updated HARMONY-4972:
-----------------------------------

    Attachment: test.rar

> unbalanced monenter/monexit  pair in HIR
> ----------------------------------------
>
>                 Key: HARMONY-4972
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4972
>             Project: Harmony
>          Issue Type: Task
>          Components: DRLVM
>         Environment: compiled by JDK5.0
>            Reporter: Chengrong Shi
>            Priority: Critical
>         Attachments: test.rar
>
>
>     I found a puzzling case of the HIR. The attachment is the picture of the HIR. In this pictrue, the control flows along the 2 in-edges of Node 98(the node whose id is 98) seem to have different lock state.The control flow from the left in-edge is unlocked at the end of Node 102, but the control flow from the right in-edge is not unlocked. Because if exception has been thrown then the last monexit of Node 102 will not been executed.
>     Is this case legal? Or I missed something else?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (HARMONY-4972) [drlvm][jit]unbalanced monenter/monexit pair in HIR

Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Fursov updated HARMONY-4972:
------------------------------------

    Summary: [drlvm][jit]unbalanced monenter/monexit  pair in HIR  (was: [drlvm][jitrino]unbalanced monenter/monexit  pair in HIR)

> [drlvm][jit]unbalanced monenter/monexit  pair in HIR
> ----------------------------------------------------
>
>                 Key: HARMONY-4972
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4972
>             Project: Harmony
>          Issue Type: Task
>          Components: DRLVM
>         Environment: compiled by JDK5.0
>            Reporter: Chengrong Shi
>         Attachments: test.rar
>
>
>     I found a puzzling case of the HIR. The attachment is the picture of the HIR. In this pictrue, the control flows along the 2 in-edges of Node 98(the node whose id is 98) seem to have different lock state.The control flow from the left in-edge is unlocked at the end of Node 102, but the control flow from the right in-edge is not unlocked. Because if exception has been thrown then the last monexit of Node 102 will not been executed.
>     Is this case legal? Or I missed something else?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.