commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kohsuke Kawaguchi <>
Subject Re: [javaflow] instrumenting 'NEW' op
Date Tue, 16 Aug 2005 05:40:07 GMT
Torsten Curdt wrote:
>> 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.)
> That's true ...Stephan introduced that
> to get rid of uninitialized objects on
> the stack.
> TBH I would like to find a different
> way of doing that. Maybe we can save
> the type of the object on the stack
> and then create a new uninitialized
> object on the restore.

I read the JVM spec and I understand the interaction between the 
verifier and the uninitialized objects better. So I think I now 
understand the reasoning behind this. When you got a Java code like this:

String v = new String(computeString());

String computeString() {
   return "abc";

then the stack capturing gets problematic because the stack contains 
uninitialized object. The transformer was trying to avoid this issue by 
performing evaluations of parameters before the 'new' instruction.

Like you said, I think it's nicer to change this so that the capturing 
would simply discard the uninitialized object and the restoration 
creates a new instance. We can infer the type of the object that needs 
to be 'new'ed from the byte code, so that information doesn't have to be 
saved in the StackRecorder.

I'm interested in fixing this, if that's OK with you.

I also learned that the byte code verifier ensures that the constructor 
can be only invoked on an uninitialized object. I guess this means that 
we can't suspend if the call stack includes a constructor. This seems 
like a rather serious limitation.

Did this limitation apply to the BRAKES project? Or did they find a way 
to work around this? like maybe by copying constructor into an ordinary 

Kohsuke Kawaguchi
Sun Microsystems         

View raw message