harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [drlvm][verifier] verifier behavior is not compatible with RI
Date Thu, 25 Jan 2007 11:49:23 GMT
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.

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