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() {
Continuation.suspend();
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 method?
-- Kohsuke Kawaguchi Sun Microsystems [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
