commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kohsuke Kawaguchi>
Subject [javaflow] instrumenting 'NEW' op
Date Sun, 14 Aug 2005 00:50:39 GMT

I've been playing with javaflow and noticed the following.

Suppose I have the following code:

	File root = new File("data");

This compiles into the following bytecode:

     // local variable 0 is "this"
     // local variable 1 is "root"

     0  new java/io/File
     3  dup
     4  ldc "data"
     6  invokespecial java/io/File/<init>(Ljava/lang/String;)V
     9  astore_1

After the instrumentation, this code expands to:

     118  ldc "data"
     120  aload 2
     122  swap
     123  invokevirtual o/a/c/j/b/StackRecorder/pushObject...
     126  new java/io/File
     129  dup
     130  aload 2
     132  invokevirtual o/a/c/j/b/StackRecorder/popObject...
     135  checkcast java/lang/String
     138  invokespecial java/io/File/<init>(Ljava/lang/String;)V
     141  astore_1

I don't think I understand the instrumentation logic completely, but 
from a cursory look, the idea is to evaluate constructor parameters 
before the 'new' op (and StackRecorder is used as a temporary place to 
store evaluated objects.)

This is actually causing an NPE if I run the above code outside the 
continuation environment (because StackRecorder is null.)

So here goes my questions:

Why is this necessary? I'd imagine it's related to restoring/capturing 
stack frames when Continuation.suspend is invoked inside a constructor, 
but it's not clear to me why we need to handle 'new's/'invokespecial's 
differently from, say, 'invokevirtual'.

Also, I noticed that the BcelClassTransformer isn't actually generating 
the stack capture/restore code for invokespecial. Is that a TODO? Is 
this related to the following line in the TODO file?

>   o fix unintialized objects for method/constructor calls

Kohsuke Kawaguchi

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message