Re: find out whether a method is called on this

"Dave Brosius" <[email protected]> Tue, 9 May 2006 21:57:21 -0400
Newsgroups gmane.comp.jakarta.bcel.user
Message-ID <002201c673d5$13c0f980$6501a8c0@MeBigFatGuy>
Yes Trinaries are very annoying. They are the only place, afaik that the 
compiler maintains a non zero sized stack across a branch.

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]
>
>