[1] http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html
On 1/22/07, Ivan Popov <[EMAIL PROTECTED]> 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].
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).
Thanks.
Ivan
On 1/19/07, Gregory Shimansky <[EMAIL PROTECTED]> 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
>
>
