Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Reducing code overhead (IAJC task problem)

Hi,
after some decompiling I discovered that a huge amount of the code overhead is due to rather unexpected behaviour (at least for me) of the
AspectJ compiler. It adds an extra set/get method pair and field to every class it process. All these classes implements a supplementary
interface - in my case it is called ElAspect.ajcMightHaveAspect. It is very surprising for me because I thought that  the "within(com.kobrix.ticl.tags.*)" in the perthis clause will limit those extra stuff only to the mentionned package.
The only workaround that I've found is to use "argfiles=com/kobrix/ticl/tags/myfile.lst" attribute in the <iajc> task and specify there (in myfile.lst) the classes that I want to be processed ("*.java" is accepted, but not for exemple "*Tag.java"). Unfortunately I'cant use any patterns to specify somehow only the needed files from this dir. Copying those files to another dir and specifying it in "srcdir" attribute doesn't seems to work, nor using <sourceroots>.  So now I have a very strange build script, which firstly builds the jar without AspectJ, moves it to the classpath, then calls <iajc> with myfile.lst, compiled files overwrite the previous ones, and then the resulting stuff is jared. No need to tell that this is at least ugly, but it saves me around 200K unneeeded code...
 
I'd like to ask if you know a better pattern for this rather common problem. Thanks in advance, Konstantin
 
        
----- Original Message -----
Sent: Monday, April 26, 2004 11:11 AM
Subject: Re: [aspectj-users] Reducing code overhead

Thanks for help. Unfortunately the difference is about 10K only. Maybe that's because I can't replace the around advices. Mistakingly I've uncommented the proceed()-s in the sample code.
I would like to ask you another question: Is it possible to eliminate from advicing sone tags, which are "empty" - e.g they don't contain any setters? I would like to do this by pointcuts, not by enumerating them, because their number is around 30 and this could change in the future.
 
Thanks in advance, Konstantin   
 
 
----- Original Message -----
Sent: Friday, April 23, 2004 3:02 PM
Subject: Re: [aspectj-users] Reducing code overhead


Try replacing the around advice with before - there will be less code generated and it doesn't look like you actually need around advice in this instance. By avoiding non-static use of thisJoinPoint (the call to getArgs()) you'll get additional savings too.

So,

>     void around() : setters() || setters1()
>     {
>         Object arg = thisJoinPoint.getArgs()[0];
>         if(arg != null)
>           savedAttributes_.put(thisJoinPoint.getSignature().getName(), arg);
>         proceed();
>     }

becomes:

before(Object arg) : (setters() || setters1()) && args(arg) {
  if (arg != null)
    savedAttributes_.put(thisJoinPointStaticPart.getSignature().getName(),arg);
}

and

>     void around() : special_setters() || special_setters1()
>     {
>         Object arg = thisJoinPoint.getArgs()[0];
>         if(arg != null)
>            savedAttributes_.remove(thisJoinPoint.getSignature().getName());
>         proceed();
>     }

becomes:

before(Object arg) : (special_setters() || special_setters1()) && args(arg) {
  if (arg != null)
    savedAttributes_.remove(thisJoinPointStaticPart.getSignature().getName(),arg);
}

I'm curious to know how much of a difference this makes in your system...

-- Adrian
Adrian_Colyer@xxxxxxxxxx


aspectj-users-admin@xxxxxxxxxxx wrote on 23/04/2004 12:05:28:

> Hi,
> We decided to use AspectJ in our product TICL. I wrote an aspect and
> everything is working, but there's a
> quite big overhead and the resulting jar has grow with around 400K. So I'd
> like to ask for some advices how
> to cut down this overhead. Let me fisrt descrive what is our aspect supposed
> to do. We have a bunch of
> classes (around 90) representing custom JSP tags, which should be modified
> in a way to provide EL support.
> We have written such classes too, but because  the code is very similar, we
> decided to use an aspect to get
> rid of those EL classes. So what is our aspect supposed to do: it should
> intercept all doStartTag(), doEndTag()
> methods, and all setters. The string setters should be handled differently
> that all other setters. I've applided every
> possible restriction taht i'm aware of, but I'm not an AspectJ expert, so
> i'd like to ask you for some help.
> The code is given below:
>
> aspect ElAspect perthis(tags())
> {
>     pointcut tags(): (this(TICLTagSupport+) || this(TICLBodyTagSupport+))
>      && within(com.kobrix.ticl.tags.*) &&
> !within(com.kobrix.ticl.tags.el.*);
>
>     //calls that must pass without our modifications
>     pointcut spec(): withincode(void ElAspect.restoreAttributes(Object)) ||
>     withincode(void ElAspect.saveAndEvaluateAttributes(Object));
>
>     pointcut setters(): execution(public void TICLTagSupport+.set*(String))
> && target(TICLTagSupport+)&& !cflow(spec());
>     pointcut setters1(): execution(public void
> TICLBodyTagSupport+.set*(String)) && target(TICLBodyTagSupport+) &&
> !cflow(spec());
>
>     void around() : setters() || setters1()
>     {
>         Object arg = thisJoinPoint.getArgs()[0];
>         if(arg != null)
>           savedAttributes_.put(thisJoinPoint.getSignature().getName(), arg);
>         proceed();
>     }
>
>     pointcut special_setters():  call(public void TICLTagSupport+.set*(*))
>     && !call(public void TICLTagSupport+.set*(String)) &&
> target(TICLTagSupport+);
>     pointcut special_setters1():  call(public void TICLTagSupport+.set*(*))
>     && !call(public void TICLBodyTagSupport+.set*(String)) &&
> target(TICLBodyTagSupport+);
>
>
>     void around() : special_setters() || special_setters1()
>     {
>         Object arg = thisJoinPoint.getArgs()[0];
>         if(arg != null)
>            savedAttributes_.remove(thisJoinPoint.getSignature().getName());
>         proceed();
>     }
>
>     pointcut doStartTag(Object tag): execution(public int
> TICLTagSupport+.doStartTag())
>     && target(tag) && !cflowbelow(execution(public int
> TICLTagSupport+.doStartTag()));
>     pointcut doStartTag1(Object tag):  execution(public int
> TICLBodyTagSupport+.doStartTag()) &&
>     target(tag) && !cflowbelow(execution(public int
> TICLBodyTagSupport+.doStartTag()));
>
>     before(Object tag) : doStartTag(tag) || doStartTag1(tag)
>     {
>         saveAndEvaluateAttributes(tag);
>     }
>
>     pointcut doEndTag(TICLTagSupport tag):  execution(public int
> TICLTagSupport+.doEndTag())
>     && this(tag) && !cflowbelow(execution(public int
> TICLTagSupport+.doEndTag()));
>     pointcut doEndTag1(TICLBodyTagSupport tag):  execution(public int
> TICLBodyTagSupport+.doEndTag())
>     && this(tag) && !cflowbelow(execution(public int
> TICLBodyTagSupport+.doEndTag()));
>
>     after(Object tag) : doEndTag(tag) || doEndTag1(tag)
>     {
>         restoreAttributes(tag);
>     }
>
>     //setXXX/value
>     private final Map savedAttributes_ = new HashMap();
>
>     private void saveAndEvaluateAttributes(Object tag)
>     {
>         //some code here
>     }
>
>     private void restoreAttributes(Object tag)
>     {
>        //some code here
>     }
> }
>
> All the tags are subclasses of TICLBodyTagSupport or TICLTagSupport.
>
> Thanks in advance, Konstantin
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users

Back to the top