harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][verifier] verifier behavior is not compatible with RI
Date Wed, 17 Jan 2007 13:22:16 GMT
I assume the TPTP profiler do it's work before the class is loaded?

Now, we *could* just go see how the Sun verifier does it, since it's  
now under the GPL.  (Don't do that until we discuss and resolve)

geir


On Jan 15, 2007, at 12:19 PM, Ivan Popov wrote:

> 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