Re: [abc-users] Capturing synchronized blocks - StmtShadowMatch or BodyShadowMatch

From: Prof. Laurie HENDREN <hendren@sable.mcgill.ca>
Date: Tue Mar 29 2005 - 17:40:51 BST

Eric,

Also, you should be aware that finding a contiguous
monitorenter/monitorexit block is impossible for general bytecode -
since there are no structural
requirements for matching monitorenter/monitorexit statements at
the bytecode level. More details in Jerome's decompiler thesis
(around page 103) at

http://www.sable.mcgill.ca/publications/thesis/#jeromeMastersThesis.

Cheers, Laurie

+-------------------------------------------------------------+
| Laurie Hendren, Professor, School of Computer Science |
| McGill University |
| 318 McConnell Engineering Building tel: (514) 398-7391 |
| 3480 University Street fax: (514) 398-3883 |
| Montreal, Quebec H3A 2A7 hendren@cs.mcgill.ca |
| CANADA http://www.sable.mcgill.ca/~hendren |
| http://wwww.sable.mcgill.ca http://aspectbench.org |
+-------------------------------------------------------------+

On Tue, 29 Mar 2005, Bruno Harbulot wrote:

> Hi Eric,
>
> This seems related to what I've done for LoopsAJ (the loop join point
> extension).
> I've extended StmtShadowMatch so that it takes a begining and an end (a
> bit like the ConstructorShadowMatch, except that "next" does not have to
> be the statement right after the main statement).
>
>
> It looks like this:
>
> package loopsaj.weaving.matching;
>
> import soot.*;
> import soot.jimple.*;
> import abc.weaving.matching.*;
>
> public abstract class StmtGroupShadowMatch extends StmtShadowMatch {
> protected Stmt lastStmt ;
>
> protected StmtGroupShadowMatch(SootMethod container, Stmt
> firstStmt, Stmt lastStmt) {
> super(container, firstStmt);
> this.lastStmt = lastStmt ;
> }
>
> public Stmt getFirstStmt() {
> return stmt ;
> }
> public Stmt getLastStmt() {
> return lastStmt ;
> }
> }
>
>
>
> I've also got NonContiguousStmtGroupShadowMatch and LoopShadowMatch
> below in the hierachy, but it's probably not relevant for this.
>
> If you want to do something with the blocks and exceptions, you can
> build the control-flow graph (with exceptions) and match the shadows on
> the blocks. I've implemented a "BlockMethodPosition" for that.
> (I'm planning to release LoopsAJ quite soon, if you'd like to have a look.)
> Regarding the around advice, you need to make sure that all the blocks
> from which you can return have got a common successor, otherwise, it
> doesn't really make sense (see our FOAL 2005 paper).
>
>
> Cheers,
>
> Bruno.
>
>
> Eric Bodden wrote:
> >
> > Hi.
> >
> > I am trying to implement a pointcut "synchronizedExecution", which
> > matches on synchronized block as synchronized(this) {...}. It has
> > basically the same matching semantics as this/target/args, so you can
> > pass in a type pattern or a formal in order to expose the bound
> > object.
> >
> > My problem at the moment is the ShadowMatch: As I understood from the
> > turorial there are matches on statements and bodies. I, however, want
> > to match on only a part of the body, being the synchronized block. So
> > what ShadowMatch should I extend?
> >
> > Identifying this block is one task. This seems quite tedious because
> > of exception handling and rethrowing in monitor regions, so the end
> > of the block seems to be hard to identify. However I think this is
> > necessary, in order to allow around() to work, is that right?
> >
> > Thanks a lot,
> > Eric
> >
> > --
> > Eric Bodden
> > RWTH Aachen University
> > ICQ UIN: 12656220, Skype: ericbodden, PGP: BB465582
> > Website: http://www.bodden.de
> >
>
Received on Tue Mar 29 17:42:53 2005

This archive was generated by hypermail 2.1.8 : Thu Mar 31 2005 - 09:40:06 BST