[Soot-list] Soot + Jikes

[Khilan Gudka]

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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20100703/a5fd9269/attachment.html