Re: [aspectj-users] lazyTJP optimization for around advice

[Andy Clement <andrew.clement@xxxxxxxxx>]

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 <amil@xxxxxx> 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
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users