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