[abc] Re: [Soot-list] Thread.holdsLock(Object)

On Tue, Oct 10, 2006 at 01:11:41PM -0400, Eric Bodden wrote:
> yes, I would like to simulate the method really, i.e. for any call to this method that is found in the call graph, one would sort of retrieve the abstract object that is passed in at this point (the points-to set) and then try to detect if there is probably (or certainly?) a lock held on this abstract object at this point in the program.

So you're saying that you want to design a static analysis to
approximate this.

Since you're presumably doing this within abc, could you perhaps make
use of the cflow analysis? Perhaps you could even use the cflow analysis
directly: make a pointcut that detects when you're inside a locked
region, take the cflow of that pointcut, and run the cflow analysis.
But, if your locked region is parameterized on a runtime lock object,
the cflow analysis won't work (won't give you any precision). As soon
as you start dealing with runtime lock objects, you need precise pointer
information. What you're asking for starts amounting to a fairly general
tracematch analysis... (i.e. have I called holdsLock() after an
entermonitor but before an exitmonitor on a given object; that's a
tracematch)

Ondrej

>
> Eric
>
>
> > -----Original Message-----
> > From: Chris Pickett [mailto:chris.pickett@mail.mcgill.ca]
> > Sent: Tuesday, October 10, 2006 11:19 AM
> > To: Eric Bodden
> > Cc: soot-list@sable.mcgill.ca
> > Subject: Re: [Soot-list] Thread.holdsLock(Object)
> >
> > Hi Eric,
> >
> > Can you explain in better detail what you want (maybe with some
> > examples)?
> > Do you mean by "simulate the native method" that you want a bytecode-
> > only version of Thread.holdsLock? Or do you want a static analysis
> > that tries to detect when Thread.holdsLock(object) will return true?
> >
> > caveat: I probably don't have an answer for you.
> >
> > Cheers,
> > Chris
> >
> > On Tue, October 10, 2006 9:17 am, Eric Bodden wrote:
> > > Hi.
> > >
> > >
> > > I thought it might be useful to simulate the native method
> > > Thread.holdsLock(Object) in Soot for some reasons...
> > >
> > >
> > >
> > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Thread.html#holdsLoc
> > > k(j
> > > ava.lang.Object)
> > >
> > > Now the problem is that the return value of this method really
> > depends
> > > on where in the code it is called. Could anyone give me some pointers
> > > of how such a method simulation is implemented best in those cases?
> > >
> > > Cheers,
> > > Eric
> > >
> > >
> > > --
> > > Eric Bodden
> > > Sable Research Group, McGill University Montréal, Québec, Canada
> > >
> > >
> > >
> > > _______________________________________________
> > > Soot-list mailing list
> > > Soot-list@sable.mcgill.ca
> > > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> > >
> > >
> >
>
> _______________________________________________
> Soot-list mailing list
> Soot-list@sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
Received on Tue Oct 10 19:49:01 2006