I assume the TPTP profiler do it's work before the class is loaded?
TPTP profiler uses JVMTI hook for class loading and instruments loaded
class right at the moment of loading its bytecode [1]. This technique
is typically used by profilers for on-the-fly instrumentation of
profiled classes using JVMTI support.
Thanks.
Ivan
[1] http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#ClassFileLoadHook
On 1/17/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
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
