You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Egor Pasko (JIRA)" <ji...@apache.org> on 2006/11/09 04:36:37 UTC
[jira] Created: (HARMONY-2114) [drlvm][jit][opt] Jitrino.OPT hides
inlined stack frames when reporting exceptional track traces
[drlvm][jit][opt] Jitrino.OPT hides inlined stack frames when reporting exceptional track traces
------------------------------------------------------------------------------------------------
Key: HARMONY-2114
URL: http://issues.apache.org/jira/browse/HARMONY-2114
Project: Harmony
Issue Type: Improvement
Components: DRLVM
Environment: any
Reporter: Egor Pasko
Priority: Trivial
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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-2114) [drlvm][jit][opt] Jitrino.OPT hides
inlined stack frames when reporting exceptional track traces
Posted by "Egor Pasko (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2114?page=all ]
Egor Pasko updated HARMONY-2114:
--------------------------------
Attachment: TestLooseInlinedFrame.java
test attached
> [drlvm][jit][opt] Jitrino.OPT hides inlined stack frames when reporting exceptional track traces
> ------------------------------------------------------------------------------------------------
>
> Key: HARMONY-2114
> URL: http://issues.apache.org/jira/browse/HARMONY-2114
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: any
> Reporter: Egor Pasko
> Priority: Trivial
> Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira