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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
