harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-2114) [drlvm][jit][opt] Jitrino.OPT hides inlined stack frames when reporting exceptional track traces
Date Sun, 15 Jul 2007 06:55:07 GMT

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

Mikhail Fursov commented on HARMONY-2114:
-----------------------------------------

Details about current implementation (changes):
1) All insts that 'throws' must have bc-mapping. I placed a several asserts checking it
2) Inlining info is derived from method markers inst.
3) Label insts (and catch labels too) are also have bc-mapping, I need it for my next task:
bc-based edge/value profiles.

This patch fixes >10 places when bc-maping was lost on call insts.
This patch makes it improssible to loose inline-info for insts, because developers does not
need to update it creating new insts.
This patch adds a lot of asserts that method markers insts have valid inline stack. There
were a lot of places where this information was lost before (but if you see JVMTI code in
OPT's emmiter you can see that these insts were used to derive inline info!)

Thats all.
Ask more detailed questions to get more detailed answers :)


> [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.


Mime
View raw message