Kohsuke Kawaguchi wrote:
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 think I realized the problem with this approach. The code below
wouldn't pass the verifier even though it's safe.
ldc 0
ifeq x
new java/lang/String
goto y
x:
new java/lang/String
y:
invokespecial java/lang/String/<init>()V
When the stack operand type is compared for two incoming control flows
to "y:", those two uninitialized String types are considered different.
I also checked the BRAKES project and they do the transformation similar
to the current transformation of javaflow (evaluate arguments before
'new') The only difference is that they use local variables to store
evaluated results.
I have to say ... the bytecode stuff is dense!
--
Kohsuke Kawaguchi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
