commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [javaflow] instrumenting 'NEW' op
Date Mon, 15 Aug 2005 21:20:27 GMT
>
> 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.

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

Well ...usually you should not run
this code outside the continuation
environment. Maybe we should try to
force that. So far that was the most
common problem people had getting
started with javaflow.

> Why is this necessary? I'd imagine it's related to restoring/ 
> capturing stack frames when Continuation.suspend is invoked inside  
> a constructor,

Yepp :)

> but it's not clear to me why we need to handle  
> 'new's/'invokespecial's differently from, say, 'invokevirtual'.

Hmmmm... not sure if we need to.
Usually I would say we don't need
to treat it differently, too.

> 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

Yes, that's about that the "new" operator.

cheers
--
Torsten

Mime
View raw message