harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Timoshenko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-2259) [drlvm][jit][opt] tests.api.java.lang.reflect.ProxyTest fails on Jitrino.OPT while passes on Jitrino.JET
Date Mon, 04 Dec 2006 08:57:24 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-2259?page=comments#action_12455255 ] 
George Timoshenko commented on HARMONY-2259:

some details of CodeSelector's bad behavior:

In HLO catch handlers are defined by two insructions:

PseudoCatchInst - is actually a LabelInst that headed the first BB after a dispatch block.
CatchInst - an instruction that defines an operand (which contains the exception)

For the pattern above we have three exception types that matches to the one catch handler.
In CFG it looks loke this (The fourth exception type is excluded from consideration):

                   /                |                  \
                  /                 |                    \
                 /                  |                      \
CatchBlock1    CatchBlock2    CatchBlock3
               \                    |                     /
                \                   |                   /
                 \                  |                 /
         (CatchHandler body starts here)

PseudoCatchInst(java/lang/Error) - starts CatchBlock1
PseudoCatchInst(java/lang/RuntimeException) - starts CatchBlock2
PseudoCatchInst(SubException) - starts CatchBlock3

CatchInst(java/lang/Throwable) - starts the catch handler's body. It's type is Throwable as
it is common ancestor for other three types.

Now to the CodeSelector. It does not care about PseudoCatchInsts at all.
Firstly it creates a set of nodes. And selects instructions one by one into them.  (PseudoCatch
is ignored but the CatchInst is not). 
Nodes that corresponds to CB1, CB2 and CB3 are empty.
Secondly selector creates edges between nodes basing on the last instructions of the nodes.
(As CB1, CB2 and CB3 are empty no edges appeare between them and catch handler's body starter)

So the information on that exception types is lost and java/lang/Throwable starts being directed
to the wrong HANDLER4.
(CodeGenerator keeps exception types on the edges, not on the Instructions as it is being
done by HLO)

The solution I proposed redirects DISPATCH->CatchBlock[1,2,3] edges to the catch handler's
body starter skipping all the way from CatchBlock[1,2,3] to the real excpetion handler.

> [drlvm][jit][opt] tests.api.java.lang.reflect.ProxyTest fails on Jitrino.OPT while passes
on Jitrino.JET
> --------------------------------------------------------------------------------------------------------
>                 Key: HARMONY-2259
>                 URL: http://issues.apache.org/jira/browse/HARMONY-2259
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux/ia32
>            Reporter: Egor Pasko
>         Attachments: H2259.java, HARMONY-2259.patch, HARMONY-2259.patch
> $subj.
> shell> $HARMONY -Xem:jet -cp $classlib/depends/jars/junit_3.8.2/junit.jar:$classlib/modules/luni/bin/test:$classlib/deploy/build/test/support.jar
junit.textui.TestRunner tests.api.java.lang.reflect.ProxyTest                            
> Time: 0.109
> OK (4 tests)
> shell> $HARMONY -Xem:opt -cp $classlib/depends/jars/junit_3.8.2/junit.jar:$classlib/modules/luni/bin/test:$classlib/deploy/build/test/support.jar
junit.textui.TestRunner tests.api.java.lang.reflect.ProxyTest
> ..F..
> Time: 0.465
> There was 1 failure:
> 1) test_newProxyInstanceLjava_lang_ClassLoader$Ljava_lang_ClassLjava_lang_reflect_InvocationHandler(tests.api.java.lang.reflect.ProxyTest)junit.framework.AssertionFailedError:
Problem converting exception
>         at tests.api.java.lang.reflect.ProxyTest.test_newProxyInstanceLjava_lang_ClassLoader$Ljava_lang_ClassLjava_lang_reflect_InvocationHandler(ProxyTest.java:145)
>         at java.lang.reflect.VMReflection.invokeMethod(Native Method)
> Tests run: 4,  Failures: 1,  Errors: 0

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


View raw message