harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Egor Pasko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-1688) [DRLVM] Jitrino.OPT crashes on ClassTest
Date Mon, 09 Oct 2006 12:20:21 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-1688?page=comments#action_12440874 ] 
            
Egor Pasko commented on HARMONY-1688:
-------------------------------------

> >JIT must not assume it has everything to be able to compile a method
> Yes, I vote to fix it in JIT once and forget about this problem forever. Otherwise it
won't be the last time we discuss this problem.
sounds reasonable, but there are a lot of other reasons...
It is not one place to fix, there are many assumptions on how VM should behave (especially
verifier) the fix will increase the uglyness of the OPT.translator and I am not feeling like
it helps somebody. A similar issue: turning verifier OFF will lead to a crash in JIT on many
synthetic bytecodes. Fixing would take a lot of effort and is the thing nobody will benefit
from, IMHO.

> 2) JITs should resolve on execution path - not at the time of compilation. 
a) not easy to do
b) that will lead to performance degradation. 
Do we really need it? I would vote not to touch the resolution strategy og OPT like that until
there is a perfect reason not to resolve so eagerly. Currently I see no reason in inserting
extra resolution helpers, performing more recompilations when references are actually resolved,
etc.


> [DRLVM] Jitrino.OPT crashes on ClassTest
> ----------------------------------------
>
>                 Key: HARMONY-1688
>                 URL: http://issues.apache.org/jira/browse/HARMONY-1688
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: debug gcc 3.3.3 DRLVM r452709
> SLES 9 32-bit SP2; CPU 2xXeon x64 (Clovertown B, 4cores)
>            Reporter: Alexey Varlamov
>
> The Jitrino.OPT fails with segmentation fault on org.apache.harmony.luni.tests.java.lang.ClassTest.

> To reproduce:
> > java -cp junit.jar:$classlib/modules/luni/bin/test:$classlib/deploy/build/test/support.jar
junit.textui.TestRunner org.apache.harmony.luni.tests.java.lang.ClassTest
> SIGSEGV in VM code.
> Stack trace:
> 	1: Jitrino::TypeManager::toInternalType(Jitrino::Type*) (??:-1)
> 	2: Jitrino::JavaLabelPrepass::JavaLabelPrepass(Jitrino::MemoryManager&, Jitrino::TypeManager&,
Jitrino::MemoryManager&, Jitrino::MethodDesc&, Jitrino::CompilationInterface&,
Jitrino::Opnd**) (??:-1)
> 	3: Jitrino::alloc_arena(Jitrino::Arena*, unsigned int) (??:-1)
> 	4: Jitrino::alloc_arena(Jitrino::Arena*, unsigned int) (??:-1)
> 	5: ?? (??:-1)
> 	6: Jitrino::MemoryManager::alloc(unsigned int) (??:-1)
> 	7: Jitrino::Tree::computeNodeOrder(Jitrino::TreeNode*, unsigned int&, unsigned int&)
(??:-1)
> 	8: ?? (??:-1)
> 	9: ?? (??:-1)
> 	10: Jitrino::JavaByteCodeTranslator::JavaByteCodeTranslator(Jitrino::CompilationInterface&,
Jitrino::MemoryManager&, Jitrino::IRBuilder&, Jitrino::ByteCodeParser&, Jitrino::MethodDesc&,
Jitrino::TypeManager&, Jitrino::JavaFlowGraphBuilder&) (??:-1)
> 	11: ?? (0015d890:15)
> 	12: Jitrino::MemoryManager::alloc(unsigned int) (??:-1)
> 	13: ?? (??:-1)
> 	14: Jitrino::JavaFlowGraphBuilder::JavaFlowGraphBuilder(Jitrino::MemoryManager&,
Jitrino::IRBuilder&) (??:-1)
> 	15: method_get_byte_code_addr (/nfs/ins/proj/drl/coreapi/avarlamo/harmony/linux.ia32/svn-repo/drlvm/vm/vmcore/src/class_support/C_Interface.cpp:365)
> 	16: ?? (??:-1)
> 	17: ?? (??:-1)
> 	18: Jitrino::JavaTranslator::translateMethod(Jitrino::CompilationInterface&, Jitrino::MethodDesc&,
Jitrino::IRBuilder&) (??:-1)
> <end of stack trace>

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

        

Mime
View raw message