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 Thu, 25 Jan 2007 12:28:45 GMT

On Jan 25, 2007, at 6:49 AM, Mikhail Loenko wrote:

> 2007/1/25, Geir Magnusson Jr. <geir@pobox.com>:
>>
>> On Jan 22, 2007, at 7:47 AM, Ivan Popov wrote:
>>
>> > I've tested instrumented class against Sun JDK 1.5 and 1.6 with
>> > -Xfuture option, which "turns on stricter class-file format checks
>> > that enforce closer conformance to the class-file format
>> > specification" [1].
>>
>> That's funny.  You'd think that the RI would "enforce conformance".
>> Not "closer", or "better", or ...
>>
>> >
>> > The instrumented class rejected by DRLVM is still accepted by  
>> Sun JVM
>> > launched with -Xfuture. I've noticed also that DRLVM does not  
>> support
>> > option -Xfuture.
>> >
>> > I think that DRLVM verifier should be compatible with RI in default
>> > mode and can provide additional option for stricter verification
>> > (-Xfuture or something DRLVM-specific).
>>
>> +1
>
> well, it's a good goal. but AFAIK they don't specify what exactly they
> are doing in the default mode.

I know.  I personally find the whole situation hilarious, even though  
we're going to have to suffer through it.

geir


>
> Thanks,
> Mikhail
>
>>
>> >
>> > Thanks.
>> > Ivan
>> >
>> > On 1/19/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
>> >> 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.
>> >>
>> >> There is always a workaround to verifier exceptions. You can  
>> run the
>> >> program with -Xverify:none to disable verifier completely. Turning
>> >> this
>> >> particular check is simple too. The question is whether this
>> >> should be a
>> >> default mode in VM or whether it should be enabled by some special
>> >> option which doesn't disable all other verifications.
>> >>
>> >> > [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
>> >> >
>> >>
>> >>
>> >> --
>> >> Gregory
>> >>
>> >>
>>
>>


Mime
View raw message