Yes, lazytjp is implemented for before advice.  You mentioned:

> But not for a combination of both before and after advice:

and yet the snippet of decompiled code you showed is a mixture of before
and around?  lazy tjp instantiation is only deliberately switched off right
now if around advice is being used. There was a good reason for this but I
honestly don't recall what it was, should be documented in the bugzillas
related to implementing the feature originally.

>  is there any way to achieve the profiling without
> and stack and without instantiating a JoinPoint?

I know you can't but do it, but using code style aspects will avoid it ...

The problem is that you need to pass in that ProceedingJoinPoint, I can
perhaps imagine an optimized form of ProceedingJoinPoint (almost a
ProceedingJoinPoint.StaticPart) that you can still proceed on but doesn't
need construction through makeJP.

You can switch to a different aspect lifecycle like perthis but that
effectively just moves 'stack management' from your code into AspectJ, it
doesn't eliminate it.

> Anyhow, it looks like 311749 is not too far off.

I'm afraid the bug doesn't actually have a target which means it isn't on
the radar to implement soon. I'll try a test run with it switched on for
around advice and see if any failing tests remind me why it isn't allowed.

cheers,
Andy


On 27 November 2012 11:57, Hmil P <[email protected]> wrote:

> I'm having fun playing with decompilers to see what is really going on and
> figuring out what is optimal
>
> Unfortunately, I cannot use the traditional AspectJ syntax for this
> project.
> However, I am able to do the proceeding inside my around advice rather than
> in Profiler.profile().
>
> Originally, I was using before+after advice as well as a stack of function
> calls to achieve the profiling, which would allow me to skip join point
> instantiation in ALL situations, *as I am only interested in
> thisJoinPointStaticPart.getSignature() and the arguments to the method
> execution*. Anyways, I decided the instantiation cost associated with
> around
> advice was less than the cost of using a stack.
>
>         @Pointcut("(execution(* Print.ech*(int))) && args(i) && if()")
>         public static boolean pc(int i, JoinPoint.StaticPart
> thisJoinPointStaticPart) {
>                 return Profiler.enabled() &&
>
> Profiler.enabled(thisJoinPointStaticPart.getSignature().getDeclaringTypeName());
>         }
>
>         @Before("pc(i, tjsp)")
>         public void beforeCall(int i, JoinPoint.StaticPart tjsp) {
>                 Profiler.begin(tjsp, new Object [] { i });
>         }
>
>         @After("pc(i, tjsp)")
>         public void afterCall(int i, JoinPoint.StaticPart tjsp) {
>                 Profiler.end(tjsp, new Object [] { i });
>         }
> -------------Decompiled woven code-------------
>         public int echo(int num) {
>                 int i = num;
>                 int j;
>                 try {
>                         if (ScrapAspect.pc(i, ajc$tjp_0))
>                                 ScrapAspect.aspectOf().beforeCall(i,
> ajc$tjp_0);
>                         j = num;
>                 } catch (Throwable localThrowable) {
>                         if (ScrapAspect.pc(i, ajc$tjp_0))
>                                 ScrapAspect.aspectOf().afterCall(i,
> ajc$tjp_0);
>                         throw localThrowable;
>                 }
>                 if (ScrapAspect.pc(i, ajc$tjp_0))
>                         ScrapAspect.aspectOf().afterCall(i, ajc$tjp_0);
>                 return j;
>         }
>
>
> Given this information, is there any way to achieve the profiling without
> and stack and without instantiating a JoinPoint?
>
> ---
> Also, it looks like lazyTJP is implemented for before advice when it uses
> thisJoinPoint (using a decompiler):
>         public int echo(int num) {
>                 int i = num;
>                 if (ScrapAspect.pc(i))
>                         ScrapAspect.aspectOf().beforeCall(
>                                         i,
>
> org.aspectj.runtime.reflect.Factory.makeJP(ajc$tjp_0, this,
>                                                         this,
> org.aspectj.runtime.internal.Conversions
>
> .intObject(i)));
>                 return num;
>         }
>
>
> But not for a combination of both before and after advice:
>         public int echo(int num) {
>                 int i = num;
>                 org.aspectj.lang.JoinPoint localJoinPoint =
> org.aspectj.runtime.reflect.Factory
>                                 .makeJP(ajc$tjp_0, this, this,
>
> org.aspectj.runtime.internal.Conversions.intObject(i));
>                 if (ScrapAspect.pc(i))
>                         ScrapAspect.aspectOf().beforeCall(i,
> localJoinPoint);
>                 if (ScrapAspect.pc(i))
>                         return org.aspectj.runtime.internal.Conversions
>                                         .intValue(echo_aroundBody1$advice(
>                                                         this,
>                                                         i,
>                                                         localJoinPoint,
>
> ScrapAspect.aspectOf(),
>
> (org.aspectj.lang.ProceedingJoinPoint) localJoinPoint,
>                                                         i));
>                 return echo_aroundBody0(this, i, localJoinPoint);
>         }
>
>
> Anyhow, it looks like 311749 is not too far off. Do you have any idea of if
> and when it would be implemented?
>
>
>
> --
> View this message in context:
> http://aspectj.2085585.n4.nabble.com/lazyTJP-optimization-for-around-advice-tp4650646p4650651.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> _______________________________________________
> aspectj-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Reply via email to