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
