[Soot-list] Soot + Jikes

[Eric Bodden]

Hi Khilan.

Thanks for the elaborate research you did. I think your diagnosis may
well be right.

> Is this a soot bug or is this the way a jvm is supposed to behave?

I really think that this is the most important question to ask here.
To me this still looks like a Jikes bug. I don't see any reason for
why the VM should rely on slot 0 not being overwritten by the program.
Slot 0 is in no way special except for the fact that the VM guarantees
that slot 0 will hold the "this reference" when an instance method is
being entered. Unfortunately, I was unable to find a passage in the VM
spec that would disambiguate this situation.

Return values are not stores in slot 0, by the way: the return value
is just the only value remaining on the operand stack. That's also why
in Jimple it has a $ in the variable name.

Eric

--
Dr. Eric Bodden
Software Technology Group, Technische Universität Darmstadt, Germany
Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt



On 3 July 2010 16:27, Khilan Gudka <khilan at doc.ic.ac.uk> wrote:
> Hi,
> Apparently this problem has been encountered by another Jikes user in the
> past:
> "Your explanation makes sense. I observed in generated classes that Soot
> reuses slot 0 as soon as possible. Soot seems to make the hypothesis that
> the VM save "this" when executing synchronized methods (as is the case in
> the Sun JVM)."
> The suggested solution was:
> "For those who might be interested, it is possible to solve this issue by
> disabling the baf local packer in soot for synchronized methods (-p
> bb.lp enabled:false)."
> Full thread:
> http://old.nabble.com/-rvm-research--Biased-unlocking-exception-when-using-soot-generated-classes-td27772333.html
> Is this a soot bug or is this the way a jvm is supposed to behave?
> Cheers,
> Khilan
> On 3 July 2010 15:10, Khilan Gudka <khilan at doc.ic.ac.uk> wrote:
>>
>> Sorry, forgot to also add the jimple code:
>>     synchronized boolean isShutdown()
>>     {
>>         org.hsqldb.Database r0;
>>         int $i0;
>>         boolean $z0;
>>         r0 := @this: org.hsqldb.Database;
>>         $i0 = r0.<org.hsqldb.Database: int dbState>;
>>         if $i0 != 16 goto label0;
>>         $z0 = 1;
>>         goto label1;
>>      label0:
>>         $z0 = 0;
>>      label1:
>>         return $z0;
>>     }
>>
>> On 3 July 2010 15:04, Khilan Gudka <khilan at doc.ic.ac.uk> wrote:
>>>
>>> Hi Eric,
>>> Thanks for the reply. I'm not so sure that it's a Jikes-only bug. In the
>>> case of hsqldb, the method which ultimate leads to a trap is
>>> org.hsqldb.Database.isShutdown().
>>> The source code is:
>>>
>>>   synchronized boolean isShutdown() {
>>>
>>>       return dbState == DATABASE_SHUTDOWN;
>>>
>>>   }
>>>
>>> The non-transformed bytecode is:
>>>
>>>   synchronized isShutdown() : boolean
>>>
>>>    L0
>>>
>>>     LINENUMBER 376 L0
>>>
>>>     ALOAD 0: this
>>>
>>>     GETFIELD Database.dbState : int
>>>
>>>     BIPUSH 16
>>>
>>>     IF_ICMPNE L1
>>>
>>>     ICONST_1
>>>
>>>     IRETURN
>>>
>>>    L1
>>>
>>>     ICONST_0
>>>
>>>     IRETURN
>>>
>>>    L2
>>>
>>>     LOCALVARIABLE this Database L0 L2 0
>>>
>>>     MAXSTACK = 2
>>>
>>>     MAXLOCALS = 1
>>>
>>> The soot-transformed code is:
>>>
>>>   synchronized isShutdown()Z
>>>
>>>     ALOAD 0
>>>
>>>     GETFIELD org/hsqldb/Database.dbState : I
>>>
>>>     BIPUSH 16
>>>
>>>     IF_ICMPNE L0
>>>
>>>     ICONST_1
>>>
>>>     ISTORE 0
>>>
>>>     GOTO L1
>>>
>>>    L0
>>>
>>>     ICONST_0
>>>
>>>     ISTORE 0
>>>
>>>    L1
>>>
>>>     ILOAD 0
>>>
>>>     IRETURN
>>>
>>>     MAXSTACK = 2
>>>
>>>     MAXLOCALS = 1
>>>
>>> In particular, I think the problem is the ISTORE 0 instructions, which if
>>> I'm not mistaken incorrectly sets local 0 = "this" to either 1 or 0
>>> depending if the values are equal or not. Isn't the return variable local 1?
>>> Thanks,
>>> Khilan
>>> On 3 July 2010 12:32, Eric Bodden <bodden at st.informatik.tu-darmstadt.de>
>>> wrote:
>>>>
>>>> Hi Khilan.
>>>>
>>>> > Anyone come across this before and know how to solve it?
>>>>
>>>> I guess it would help more to ask the Jikes developers. In the
>>>> transformed program runs on other VMS then clearly this error is due
>>>> to a bug in Jikes, not in Soot. At our lab we have some experience
>>>> with Jikes and from what I have heard it's not uncommon for Jikes to
>>>> fail on larger programs.
>>>>
>>>> Eric
>>>
>>
>
>