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
PGP.sig
Description: This is a digitally signed message part
