[Soot-list] is this a bug in MHP analysis?

[Richard L. Halpert]

After taking a more in-depth look, I rescind my previous comment.  Your
patch is correct.  My apologies!

I just committed your changes along with some tweaks and general cleanup in
revision 3515.  Thanks for finding this problem and providing a solution!

-Richard

On Wed, Jun 30, 2010 at 9:19 PM, Richard L. Halpert <richhal22 at gmail.com>wrote:

> Peng,
> I've been looking into this issue and so far I've been unable to reproduce
> the problem on a toy example based on what you described (attached).
> However, at the moment I don't have access to a copy of SpecJBB (my old
> development machine died recently), so I haven't been able to do a
> full-fledged test.  Nonetheless, I agree that it looks like the
> AllocNodes/MultiCalledMethods/MultiRunStatements trio doesn't really compute
> a proper fixed point.  This coming weekend I hope to have some free time to
> investigate the problem more thoroughly.
>
> I'm not convinced that your patch fixes the problem, because it still
> wouldn't compute a fixed point... rather, it simply adds one more iteration
> in the MCM->MRS->MCM loop.  Still, this is probably enough to work for most
> programs, so you can use it for now.
>
> -Richard
>
>
> On Sun, Jun 27, 2010 at 6:39 AM, peng <lpxz at ust.hk> wrote:
>
>> Dear All:
>>   I find a problem when using the  MHPAnalysis, is this a bug?
>>    During the mhp analysis of Specjbb:
>>           JBBmain.java
>>           DoArun():
>>             for (whID = 1; whID <= number_of_warehouses; whID++) {
>>                myCompany.startAutomated(whID, rampup_time,
>> measurement_time);
>>                startJBBthread(whID);
>>                ...
>>             }
>>           startJBBthread(int whID):
>>           {
>>              Thread whThread = new Thread(this);
>>              whThread.start();
>>           }
>> I find a problem: the abstract thread modeled for whThread  may happen
>> in parallel with itself, in another word, another copy of the abstract
>> thread should be contained in the MHPlist, and the MHP should contain
>> totally 3 threads: abstract thread for whThread, a copy of it,
>> and the main thread. But the mhpAnalysis reports: MHP contains 2
>> threads, abstract thread, the main thread.
>>
>> During the inspection of the code, I find the  following if-branch in
>> MHPanalysis is not covered,  but should be covered:
>>                        if(mayStartMultipleThreadObjects &&
>> mayBeRunMultipleTimes)
>>                        {
>>                                MHPLists.add(thread); // add another copy
>>                        }
>> the reason is that mayStartMultipleThreadObjects=false, while it should
>> be true.
>>
>> The reason for the wrong value of mayStartMultipleThreadObjects is :
>> multiRunAllocNodes.contains() should returns true, while it returns
>> false.
>>
>> boolean mayStartMultipleThreadObjects =(threadAllocNodes.size() > 1) ||
>> so.types_for_sites();
>> if(!mayStartMultipleThreadObjects)
>>
>>        if(multiRunAllocNodes.contains(threadAllocNodes.iterator().next()))
>>        //but the anode corresponds to multiple objects..
>>         {
>>         mayStartMultipleThreadObjects = true;
>>          }
>> }
>>
>>
>> after looking into the AllocNodeFinder.java, I find the roots of  the
>> problems.
>> AllocNodeFinder first locates the MultiCalledMethod (McallM), then
>> compute the MultiRunStmt(MRunS).
>> this computation is problematic,
>> because the McallM can be influenced by the MRunS. and also, the MRunS
>> can be influenced by MCallM.
>> the computation can be simplified as:
>> 1 MRunS_orig| McallM_on_CG -> MCallM
>> 2 McallM-> McallM_prop
>> 3 MCallM_prop|MRunS_orig-> MRunS
>>
>> For Step1:
>> (when we compute the MCallM, we must take the MRunS_orig into account,
>> i.e., the for-loop, but the implementation simply misses the for-loop
>> during the computing of MCallM, and also, there is no fixpoint-style
>> computation later, that is also why the MHPanalysis reports whThread in
>> specjbb does run for multiple times.)
>> For Step2:
>> (the propagation is  placed in a wrong place in the original
>> implementation, actually nothing is propagated in the original version,
>> that is also the reason why a concurrencyModificationException in
>> propagate is not triggered)
>> For step3:
>> (This is implemented in the AllocNodeFinder.find() method, and no
>> problem)
>>
>> Is this really a bug in soot2.4.0 ??
>> Thanks in advance.
>>
>>
>> Regards
>> Peng
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20100713/32ff4353/attachment.html