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] Created: (HARMONY-2088) [drlvm] [verifier] Verifier allows type inference to fail on values recieved by pop instruction
Date Tue, 07 Nov 2006 14:46:53 GMT
[drlvm] [verifier] Verifier allows type inference to fail on values recieved by pop instruction
-----------------------------------------------------------------------------------------------

                 Key: HARMONY-2088
                 URL: http://issues.apache.org/jira/browse/HARMONY-2088
             Project: Harmony
          Issue Type: Bug
          Components: DRLVM
         Environment: any
            Reporter: Egor Pasko
            Priority: Minor


as specified in [1] :

Verification by type inference must be supported by *all Java virtual machines*, except those
conforming to the JavaCard and J2ME CLDC profiles.

as described later in [1] (under "Verification by type inference"):

To merge two operand stacks, the number of values on each stack must be identical. The types
of values on the stacks must also be identical, except that differently typed reference values
may appear at corresponding places on the two stacks. In this case, the merged operand stack
contains a reference to an instance of the first common superclass of the two types. Such
a reference type always exists because the type Object is a superclass of all class and interface
types. If the operand stacks cannot be merged, verification of the method fails.

However, DRLVMs verifier only checks that "Structural constraints" are met. In case of unmergable
types used only by pop instruction, verification passes. Consider the following test:
--------------------- begin Test.j ----------------------
.class public Test
.super java/lang/Object

.method public static main([Ljava/lang/String;)V
.limit stack 2
.limit locals 3

    iconst_0
    iconst_0
    ifne Label0
    pop
    fconst_0
Label0:
    pop
    return

.end method
--------------------- end Test.j ----------------------
to reproduce the failure:
* obtain jasmin.jar from [2]
* compile the test into a class file:
   java -jar jasmin.jar Test.j
* $HARMONY -Xem:opt Test

with that you get it crashed:
SIGSEGV in VM code.
Stack trace:
        1: Jitrino::JavaByteCodeTranslator::offset(unsigned int) (??:-1)
        2: Jitrino::JavaByteCodeParserCallback::parseByteCode(unsigned char const*, unsigned
int) (??:-1)
        3: Jitrino::JavaTranslator::translateMethod(Jitrino::CompilationInterface&, Jitrino::MethodDesc&,
Jitrino::IRBuilder&) (??:-1)
        4: Jitrino::TranslatorSession::translate() (??:-1)
        5: Jitrino::TranslatorSession::run() (??:-1)
        6: Jitrino::runPipeline(Jitrino::CompilationContext*) (??:-1)
        7: Jitrino::compileMethod(Jitrino::CompilationContext*) (??:-1)
        8: Jitrino::Jitrino::CompileMethod(Jitrino::CompilationContext*) (??:-1)
        9: JIT_compile_method_with_params (??:-1)
[snip]

that's because Jitrino.OPT cannot handle this kind of incorrect java bytecode. RI throws VerifyError
here. On Jitrino.JET the test does not crash the VM. 

There are 2 issues here to look at:
1. Verifier allows the code that does not comply with the spec update [1]
2. Jitrino.OPT sometimes crashes on unverifiable bytecodes

this issue describes (1). If you think that Jitrino.OPT should not crash on any bytecode (which
is (2)), feel free to file another issue for that. Crash-free translation is not easy with
incorrect bytecodes. May require a strong Java Translator refactoring.

[1]  http://java.sun.com/docs/books/vmspec/2nd-edition/UpdatedClassFileFormat.pdf 
[2]  http://jasmin.sourceforge.net/

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