mirrors
/
org.aspectj
mirror of https://github.com/eclipse/org.aspectj.git


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156
							<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html> <head>
<title>AspectJ 1.6.1 Readme</title>
<style type="text/css">
<!--
  P   { margin-left:  20px; }
  PRE { margin-left:  20px; }
  LI  { margin-left:  20px; }
  H4  { margin-left:  20px; }
  H3  { margin-left:  10px; }
-->
</style>
</head>

<body>
<div align="right"><small>
&copy; Copyright 2008 Contributors.
All rights reserved.
</small></div>

<h1>AspectJ 1.6.1 Readme</h1>

<p>The main themes of AspectJ1.6.1 are better memory usage and faster weaving.
This has been achieved through profiling of the weaving process and has
resulted in some serious refactoring of the weaver component within AspectJ.  It provides
exactly the same functionality as in previous releases, it just weaves faster now, using
less code and less memory.  This readme will give an overview of the kind of changes
made and what can be expected when using 1.6.1 compared to previous releases.</p>

<p>The complete list of issues resolved for AspectJ 1.6.1 can be found with
these bugzilla queries.  The first lists bugs addressed (more than 60!) whilst the second details
enhancements made in this release.</p>
<ul>
<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Bugs resolved</a>
<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_severity=enhancement&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Enhancements implemented</a>
</ul>
<hr>

<h2>Refactored (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=231396">bug 231396</a>)</h2>

<p>The bugzilla entry goes into more specifics on what has changed, the end result is that aspectjweaver.jar has had around 275 classes removed (about 25%) and 
has slimmed down by 350k (about 20%).  In terms of performance for different scenarios:

<h4>Straight compilation</h4>
<p>The refactoring effort has been focused on the weaver component, hence there is limited impact on the performance of source compilation but this comparison shows it is faster.  Four scenarios are compared, in each scenario a different aspect
is applied to the JDT compiler (just as a sample piece of source code).
<ol>
<li>1100 source files, few aspects that target 859 join points.
<li>1100 source files, code style trace aspect targeting public methods (22000 join points)
<li>1100 source files, annotation style trace aspect (22000 join points)
<li>1100 source files, insane aspect (before(): within(*) {}) (203000 join points)
</ol>
<p>
<center>
<img src="perfSourceCompile_161.jpg"></img>
</center>

<h4>Binary weaving</h4>
<p>Moving on from source compilation to pure binary weaving, the improvements are more obvious.  Here we are using the complete JVM 
classes jar 'rt.jar' as an example of a large jar file for weaving.
<ol>
<li>Binary weaving rt.jar (~12000 classes) with a simple aspect (1200 join points)
<li>Binary weaving rt.jar (~12000 classes) with a code style trace aspect (121000 join points)
<li>Binary weaving rt.jar (~12000 classes) with an annotation style trace aspect (121000 join points)
<li>Binary weaving rt.jar (~12000 classes) with an insane aspect (before(): within(*) {}) (352000 join points)
</ol>
<center>
<img src="perfBinaryWeave_161.jpg"></img>
</center>

<h4>Loadtime weaving</h4>
<p>The loadtime weaving improvements are similar to those seen for binary weaving (naturally).  Here we are using the JDK 
tools jar 'tools.jar' as an example of a jar file for loadtime weaving.
<ol>
<li>Binary weaving tools.jar (~1900 classes) with a code style trace aspect
<li>Binary weaving tools.jar (~1900 classes) with an insane aspect (before(): within(*) {})
</ol>
<center>
<img src="perfLTW_161.jpg"></img>
</center>
<p>The refactoring work has also reduced the amount of unnecessary garbage created on the heap during the weaving process.  The next comparison shows roughly the
reduction in amount of 'stuff' created on the heap during a weave.  This isn't the max heap required to do a weave, it is just showing how many less temporary objects
are allocated during an entire run of the weaver
<ol>
<li>First, the number of kilobytes of memory allocated from the heap during a weave of tools.jar with a code style trace aspect
<li>Second, another run of the same thing
<li>Third, this time using the insane aspect
</ol>
<center>
<img src="heapContents_161.jpg"></img>
</center>
<p>So in terms of memory required, weaving the insane aspect into tools.jar created 1.4G of 'stuff' over the entire weaving process, compared to 1.75G with 1.6.0.

<h4>Loadtime weaving stress</h4>
<p>As well as addressing the memory usage of a single load time weaver, we have also looked at the use of load time weaving in a larger
scale scenario, where multiple classloaders are being instantiated and discarded over time and each has an associated load time weaver.
Under <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=210470">bug 210470</a> we looked in detail at whether the lifecycle of the
weaver instance correctly matched the lifecycle of the associated classloader.  It did not, but now it does!

Here is a memory usage graph for AspectJ1.6.1 - this shows an application that spawns 7 threads which run continuously for a few minutes.  Each thread
repeatedly creates a classloader, weaves 500 classes using it then discards the classloader.  You can see that over time the memory is recovered
correctly and when all threads complete (and all classloaders are orphaned), all the weavers are discarded.

<p>First, AspectJ 1.6.0, in which memory was never correctly recovered and so an OutOfMemory problem would always occur eventually.
<center>
<img src="memLtwStress_160.jpg"></img>
</center>
<p>And now AspectJ 1.6.1:
<center>
<img src="memLtwStress_161.jpg"></img>
</center>


<h2>Incremental compilation</h2>
<p>Following on from the work done to improve compilation under Eclipse in AspectJ 1.6.0 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427">Bug 221427</a>
) - we now support the building of 'broken code' (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=102733">bug 102733</a>).  This is something the JDT 
has always been doing - where code containing errors continues to build (if recovery is possible) but should the actual methods containing the errors get 
invoked, an exception will be thrown at runtime.  A number of users typically extract large projects from their library
systems, knowing that they will only partially build in their current eclipse setup, but as long at they do not invoke the code containing the errors then
they expect the rest of the project to run normally.  AspectJ now allows this mode of operation, and it has the additional effect that the state
of the project stays consistent, albeit with known errors, and this means AspectJ will more frequently do incremental builds rather than falling back
to full builds because there was a compilation error.

<h2>Language changes</h2>
<h4>Optmized syntax for annotation value binding (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=234943">Bug234943</a>)</h4>
<p>If only binding an annotation at a method-execution join point in order to access an <b>enum value</b>
within it, there is a more optimal syntax that can be used to produce faster code.
Given this setup:</p>
<code><pre>
enum Colour { RED,GREEN,BLUE;}

@interface ColouredAnnotation { Colour value(); }

@ColouredAnnotation(Colour.RED)
public void colouredMethod() { }
</pre></code>

<p>Current syntax:</p>
<pre><code>
before(ColouredAnnotation anno): execution(* *(..)) && @annotation(anno) {
  printTheColour(anno.value());
}
</pre></code>
<p>New optional syntax:</p>
<code><pre>
before(Colour col): execution(* *(..)) && @annotation(ColouredAnnotation(col)) {
  printTheColour(col);
}
</pre></code>

<hr>


<!-- ============================== -->
  
</body> </html>