From: aclement Date: Mon, 20 Nov 2006 10:29:29 +0000 (+0000) Subject: 153 readme - draft X-Git-Tag: V1_5_3_final~10 X-Git-Url: https://source.dussan.org/?a=commitdiff_plain;h=7143428801aa03299b6ff1651df7012097024576;p=aspectj.git 153 readme - draft --- diff --git a/docs/dist/doc/README-153.html b/docs/dist/doc/README-153.html new file mode 100644 index 000000000..45b5911fe --- /dev/null +++ b/docs/dist/doc/README-153.html @@ -0,0 +1,104 @@ + + +AspectJ 5 Development Kit v1.5.3 Readme + + + + +

+ +

AspectJ 5 v1.5.3 Readme

+ +

This release includes a number of bug fixes and a few enhancements (over 80). The full list of resolved issues can be found with + +this bugzilla query. +

+Notable changes since the 1.5.2 release include: +
+ +

Pipeline compilation - 146781

Until this release, the memory profile for AspectJ looked like this (time is along the X axis, memory usage is the Y axis)

+ +

+     /\_
+    /   \_
+   /      \_
+  /         \_
+ /            \_
+/               \
+

+The first phase (as we go up and up and up) is the compilation of every file - when the peak is reached we then start weaving files one by one, discarding them once woven and dumped to disk. + +In 1.5.3 we don't compile everything up front - we compile and weave files one at a time. Giving us this profile: +

+  /\  /\  /\
+ /  \/  \/  \
+/            \
+

+Each peak is compiling a file, then it is woven, dumped to disk and the space recovered (the trough) - we then move onto the next file. + +What does this mean? The peaks are far far lower, so you need far less memory to compile a project. For example, I have a 1000file project, affected by aspects at >750 join points. + +For given values of Xmx, here are the times taken to compile it (on the command line) with AspectJ1.5.2:


+Xmx  Time
+512M 33seconds
+256M 40seconds
+220M 116seconds
+212M OutOfMemory
+

+ +

The times gradually increase as the memory is reduced as the VM is thrashing in garbage collection. + +Here are the results for AspectJ1.5.3:


+Xmx  Time
+512M 33s
+256M 33s
+180M 33s
+140M 33s
+100M 35s
+80M  43s
+70M  OutOfMemory
+

+ +

So with 1.5.3, it isn't until around 80M that the VM starts to struggle with memory. These savings will affect any code built from source: on the command line, in Ant, +or in AJDT. It will not affect binary weaving - that is a future enhancement.

+ + +

Serviceability - 150487

As AspectJ grows in popularity, we find that it is becoming more difficult for users to come up with the small testcases +that recreate problems - the usage scenarios for AJ are becoming more and more sophisticated. To help us work on +problems in these scenarios we have added a tracing and logging framework and improved our dump mechanism. These traces and +dumps can be attached to bug reports. In AspectJ 1.5.3 we have included +some documentation on how to configure these new features. Don't be surprised if you get asked +for an AspectJ trace on a future bug report! +

+ +

LTW enhancements

+ +

132080 describes how the +concrete aspects that can be defined in aop.xml are now exposed for weaving.

149289 + +

+ +

For information on bug fixes in AspectJ 5 v1.5.3, see the changes document.

+ + +