[jira] Resolved: (HARMONY-2114) [drlvm][jit][opt] Jitrino.OPT hides inlined stack frames when reporting exceptional track traces

["Mikhail Fursov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Fursov resolved HARMONY-2114.
-------------------------------------

    Resolution: Fixed

Commited as r 556007

> [drlvm][jit][opt] Jitrino.OPT hides inlined stack frames when reporting exceptional track traces
> ------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-2114
>                 URL: https://issues.apache.org/jira/browse/HARMONY-2114
>             Project: Harmony
>          Issue Type: Improvement
>          Components: DRLVM
>         Environment: any
>            Reporter: Egor Pasko
>            Assignee: Mikhail Fursov
>            Priority: Trivial
>         Attachments: jit.patch, TestLooseInlinedFrame.java
>
>
> consider the following test:
> ---------------------------------------------------------
> public class TestLooseInlinedFrame
> {
>     public static void main(String[] args)
>     {
>         try {
>             toInline();
>         }catch (RuntimeException e) {
>             e.printStackTrace();
>         }
>     }
>     public static final void toInline()
>     {
>         throw new RuntimeException();
>     }
> }
> ---------------------------------------------------------
> the "fair" output would be as on JET or interpreter:
> java.lang.RuntimeException
>         at TestLooseInlinedFrame.toInline(TestLooseInlinedFrame.java:14)
>         at TestLooseInlinedFrame.main(TestLooseInlinedFrame.java:6)
> on OPT (-Xem:opt) one frame is missing:
> java.lang.RuntimeException
>         at TestLooseInlinedFrame.main(TestLooseInlinedFrame.java:10)
> that is because:
> a) one method was inlined (toInline())
> b) the method is exited via exception
> currently, Jitrino.OPT _allows_ reporting inlined frames, but only those CALL-ed through. To make it real OPT preserves inline information for each inlined CALL instruction. To implement similar approach for exceptional exits we need one of two:
> * preserve inline information on each potentially exceptional instruction (basic block?) // memory footprint is sensitive to it
> * mark inlined method's boundaries // requires to update info during all code motions
> Both approaches have major disadvantages, that is why I am setting priority so low. Any alternative suggestions are welcome.

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