Re: find out whether a method is called on this

Dave Brosius wrote:

> Yes Trinaries are very annoying. They are the only place, afaik that 
> the compiler maintains a non zero sized stack across a branch.

Hello Dave,

Thanks for your reply.
Do you know another way of knowing whether a function is called on the 
'this' object?

Btw, I ran accross another construct that had the same problem
            drawObject2(startNr == selectedNr && isFocused()); 
which result in the following bytecode
    aload_0[42](1)
    aload_0[42](1)
    getfield[180](3) 55
    aload_0[42](1)
    getfield[180](3) 57
    if_icmpne[160](3) -> iconst_0
    aload_0[42](1)
    invokespecial[183](3) 61
    ifeq[153](3) -> iconst_0
    iconst_1[4](1)
    goto[167](3) -> invokespecial 74
    iconst_0[3](1)
    invokespecial[183](3) 74
    return[177](1)

Is this also covered by the OpcodeStack?

Kind Regards,

Marc

>
> The findbugs.sourceforge.net class OpcodeStack attempts to merge 
> stacks across trinaries. You might find that useful.
>
> cheers!
> dave
>
> ----- Original Message ----- From: "Marc Van Daele" 
> <[email protected]>
> To: <[email protected]>
> Sent: Tuesday, May 09, 2006 9:49 AM
> Subject: find out whether a method is called on this
>
>
>> Hello,
>>
>> I'm (trying to) writing a deadlock detection tool.
>> This works now relatively fine but it generates way too many false 
>> positives
>> since too many virtual functions are expanded.
>>
>> To limit this, I want to find out whether a method is called on 'this'
>> since then I can limit the expansion.
>>
>> Hence my question: Is there an easy way in BCEL to find out whether a 
>> method is called on 'this' vs on another object?
>>
>> I tried the following:
>> I know that ALOAD_0 pushes the this pointer to the stack.
>> So by using Instruction.consumeStack and Instruction.produceStack, I 
>> try to model the stack and
>> derive whether the method-call got executed on 'this' or on another 
>> object.
>>
>> However, this fails, at least in the following code fragment
>>        drawObject2((b)?true:false); which is translated in bytecode to
>>    aload_0[42](1)
>>    aload_0[42](1)
>>    getfield[180](3) 70
>>    ifeq[153](3) -> iconst_0
>>    iconst_1[4](1)
>>    goto[167](3) -> invokespecial 74
>>    iconst_0[3](1)
>>    invokespecial[183](3) 74
>> Since I only use consumeStack and produceStack (and don't bother with 
>> branches), I put an object on the stack for both iconst instructions
>> and hence I incorrectly conclude that invokespecial is called on 
>> iconst_1 which isn't this.
>>
>> Input is appreciated,
>>
>> Marc
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>