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

> -----Original Message-----
> From: Ondrej Lhotak [mailto:olhotak@uwaterloo.ca]
> Sent: Tuesday, October 10, 2006 2:49 PM
> To: Eric Bodden
> Cc: Christopher J F Pickett, Mr; ABC mailing list
> Subject: 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)

Hehe, that's sort of funny. My idea was that if one had a proper "simulation" of Thread.holdsLock(Object) one could use *that* to sort of find synchronized regions. The problem with your suggestion is that it's everything but straightforward to "make a pointcut that detects when you're inside a locked region". So my idea was to use Thread.holdsLock(Object) to detect whether this is the case. This should work dynamically but without properly simulating it during callgraph construction, we cannot do anything about it statically.

See what I mean?

Eric

>
> 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#holdsL
> > > oc
> > > > 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:57:29 2006