commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kohsuke Kawaguchi ...@kohsuke.org>
Subject Re: [javaflow] instrumenting 'NEW' op
Date Wed, 17 Aug 2005 01:02:57 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message