Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-dev] FW: [aspectj-users] Using AOP to implement double dispatching technique

Fyi, I've linked this message in a new compiler design document that we
should start expanding: docs/developer/compiler.html

If you recall or come across mailing lists post that contain language or
compiler documentation you can add them to the developer docs by doing an
eclipse.org search for a quoted portion of the message and adding that link
to the corresponding HTML page.  E.g. Jim's message gives the following
link:

http://dev.eclipse.org/mhonarc/lists/aspectj-dev/msg00430.html

Mik 

--
http://kerstens.org/mik
 
> -----Original Message-----
> From: aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx]
> On Behalf Of Jim.Hugunin@xxxxxxxx
> Sent: Friday, July 18, 2003 9:20 AM
> To: aspectj-dev@xxxxxxxxxxx
> 
> I want to explain ajc-1.1's implementation of introduction so that the
> reasons behind the two "unneeded" static methods will be more clear.  The
> short answer is that these methods improve the modularity and separate-
> compilation of the ajc compiler and its generated code.
> 
> When implementing things this way, I believed that the performance over-
> head in any real application running on a reasonable JIT would be so small
> as to not be noticeable -- static methods should be very easy for a JIT to
> inline.  I hope that Adrian can get some help on understanding the details
> of this from some real JVM performance experts to confirm or deny this
> assumption -- or possibly suggest some tweak to the implementation to make
> the JIT's happier.  I also think that Wes is on the right track by
> pointing out the advantages of the simpler solutions possible in AspectJ.
> 
> <details>
> Here's a sketch of how ajc-1.0 and ajc-1.1 implement an introduced method
> (actual mangled names are longer with much better hygiene guarantees):
> 
> aspect A {
>   void C.m() { <body of C.m> }
> }
> 
> class Main {
>   public static void main(String[] args) {
>     new C().m();
>   }
> }
> 
> ==(ajc-1.0)==>
> 
> class A { }
> 
> class C {
>   void m$from$A() { <body of C.m properly moved to class C> }
> }
> 
> class Main {
>   public static void main(String[] args) {
>     new C().m$from$A();
>   }
> }
> ==(ajc-1.1)==>
> 
> class A {
>   static void C$m(C self) { self.m$from$A(); }
> 
>   static void C$m$body(C self) { <body of C.m> }
> }
> 
> class C {
>    void m$from$A() { A.C$m$body(this); }
> }
> 
> class Main {
>   public static void main(String[] args) {
>     A.C$m(new C());
>   }
> }
> ------------------------------------------
> 
> The two extra static methods were added for different reasons.
> 
> A.C$m(C self): This method was added to improve the error messages in the
> case of separate compilation or weaving where the build process is broken.
> If A and Main are compiled without the ability to weave into C, then ajc
> will display an Xlint warning message and continue to generate the
> partially correct code.  This makes it possible to postpone the weaving
> into C possibly until class load time.  With this method, if the
> programmer forgets to weave into C before running the program, she will
> see some sort of JVM error coming from A.C$m that will give some context
> to the problem.  Without this method, the error will come from Main.main
> and will typically not include enough information for the issue to even
> make sense.  I can easily see removing this method with some very minor
> performance evidence coupled with some work understanding the separate
> compilation use-cases.
> 
> A.C$m$body(C self): This method keeps the body of the introduced method
> inside of A rather than moving it to C.  This keeps the body of the method
> in the same Java lexical scope that the compiler analyzes it in.  This
> means that stack-traces and debuggers can both understand the correct
> files and line numbers inside this code without any AspectJ awareness.  It
> also removes the need to expose A's private members and package-visible
> members from A's package to the world so they can be accessed from C.
> Finally, it improves the incremental compilation properties by allowing
> changes to the body of the method to only force a recompile of A and not
> C.  I think you'd need to find some extremely strong performance problems
> to argue for moving the body of this method back into C.
> 
> -Jim
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev



Back to the top