harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Popov" <ivan.g.po...@gmail.com>
Subject [drlvm][verifier] verifier behavior is not compatible with RI
Date Mon, 15 Jan 2007 15:19:12 GMT
I'd like to discuss the problem with Eclipse TPTP profiler working
with DRLVM, which is described in HARMONY-2905 [1].  The problem is
that verifier in DRLVM rejects class instrumented by TPTP profiler.

TPTP profiler instruments class bytecodes by enclosing each method
call into try-finally block, in order to report correctly entry/return
of this method. It instruments calls of all methods including
invocation of super() in constructors of class instance. Here is
fragment of instrumented bytecodes:

         <…>
    try {
    19: aload_0 #0=this
    20: invokespecial #8=<Method java.lang.Object.<init> ()void>
    23: goto_w 28
    28: nop
    29: ldc_w #62=<Integer 70056>
    } finally {
         <…>

This leads to the value of 'this' variable, which is considered
uninitialized before call to super(), is used inside try-finally
block. This contradicts to the JVMS spec 2nd edition [2], which states
in the last paragraph of section 4.9.4:

    A valid instruction sequence must not have an uninitialized object
    on the operand stack or in a local variable during a backwards branch,
    or in a local variable in code protected by an exception handler
    or a finally clause. Otherwise, a devious piece of code might fool
    the verifier into thinking it had initialized a class instance when it had,
    in fact, initialized a class instance created in a previous pass
through a loop.

And another statement in proposed changes for JDK 1.5 in "Class file
format" [3] in section 4.11.1 (which is new item in this proposal):

    -- There is never an uninitialized class instance in a local
variable in code protected
    by an exception handler. However, an uninitialized class instance may
    be on the operand stack in code protected by an exception handler. When an
    exception is thrown, the contents of the operand stack are discarded.

Verifier in DRLVM follows these statements and rejects class bytecodes
instrumented in such a way. However, both Sun JDK version 1.5 and 1.6
and  JRockit JDK 1.5 accept such instrumented class. Either they just
ignore these statements or interpret 'uninitialized' status of 'this'
variable in a different way.

I've submitted bug against TPTP profiler [4], which produces incorrect
instrumentation, and this bug was accepted by TPTP developers to be
fixed in the next release. However, this is a general approach for
instrumenting method calls and any other Java profiler may use it and
work fine with RI, but and face this problem with DRLVM. I think it
makes sense to adjust DRLVM verifier to follow RI behavior. I'd like
to see comment from DRLVM gurus.

Thanks.
Ivan

[1] https://issues.apache.org/jira/browse/HARMONY-2905
[2] http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#9839
[3] http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=170075

Mime
View raw message