FAQ

UDDT_PATH holds the path to the directory where Arachne is installed (/usr/local/Arachne)
PATH holds the path to the Arachne command line tools (/usr/local/Arachne/bin)
LD_LIBRARY_PATH holds the path to the Arachne shared libraries (/usr/local/Arachne/lib)
UDDT_ASPECT_PREPROCESSOR holds the path to the Arachne preprocessors that translates the aspect code into legacy C code (/usr/local/Arachne/bin/aspect-preprocessors/FunctionCall/preprocessor:/usr/local/Arachne/bin/aspect-preprocessors/ReadGlobalVariable/preprocessor)

To free the user from the burden of setting these variables, a shell script is provided. In every bash shell where you want to issue Arachne commands, just do once:

source /usr/local/Arachne/site/sourceMe.bash

4 - How do I compile an aspect?

Start by setting the appropriate envrionment variables since you will need to use the Arachne aspect compiler.

The aspect compiler takes an aspect source code file and generates a shared library. This shared library contains the compiled aspect.

For example:

acc Aspect.so Aspect.ac

will generate a shared library named Aspect.so holding the compiled aspects defined in the Aspect.ac file.

Any additional arguments will be passed as if to gcc. Hence:

acc Aspect.so Aspect.ac foo.o bar.so -g

will generate a shared library named Aspect.so:

holding the aspects defined by Aspect.ac
holding the code contained in the foo.o
dynamically linked with bar.so
with C debugging information (-g)

5 - How do I weave/deweave an aspect?

Arachne provides a dynamic weaver: aspects are woven on running programs identified through their pid.

In a first shell, run your base program by typing:

run ./baseProgram

(if your shell complains because it can not find run see question 3)

In a second shell, weave the aspects contained in a library in the base program by typing:

weave baseProgramPid WEAVE pathToAspectLibrary (i.e. for example weave 1789 WEAVE ./Aspect.so)

(if your shell complains because it can not find weave see question 3)

In this second shell, deweave the aspects contained in a library in the base program by typing:

weave baseProgramPid DEWEAVE pathToAspectLibrary (i.e. for example weave 1789 DeWEAVE ./Aspect.so)

Be careful: the path to the aspect library is relative to the base program not your path when you issue a weave command. It is always safe to use absolute paths in the arguments given to weave.

Weaving aspects in a given program will generate a few additional libraries in the base program working directory. These libraries hold meta data that are uses by Arachne at weaving time.

If you need a clue to choose the appropriate pid number, the command

ls /usr/local/Arachne/tmp/unix-socket/

might help.

6 - Are there any examples?

A prefetching example for squid is available from the download area. It lacks however comments and documentation.

The current distribution contains a few examples. There are located under /usr/local/Arachne/Test. These examples are simply meant to check your installation. In particular, they are not meant to be a tutorial.

7 - Where does the name Arachne come from?

Arachne is named after an ancient Greek myth. Arachne was a Greek girl who was a very skilled at spinning and weaving. Athena was the goddess of wisdom and also taught the art of spinning and weaving. Arachne challenged Athena to a contest although Athena warned her she would not win. Athena was furious and flew down to earth disguised as an old woman. She went to Arachne's hut where she was weaving a pattern of rainbow colored threads. Athena warned Arachne not to compete with a goddess. But, Arachne said that she was the finest weaver in the world, and if Athena didn't believe her to let her come and have a contest. Then, Athena revealed herself and accepted the challenge. Athena and Arachne set up their looms and went to work using all shades of every color thread. Athena wove into her cloth the Olympian gods and all their glory and majesty. Arachne wove an irreverent scene making fun of Zeus and his wives.

8 - How does Arachne works? Is it just hacking? Are you assuming that the base program has been compiled with a specific compiler?

At weaving time, Arachne rewrites the IA-32 instructions interpreted by the processor.

Arachne is not a hack. Arachne exploits the published standards. These standards are:

Intel specifications explaining how the processor interprets each instruction: Intel Architecture Software Developer’s Manual Volume 1, Volume 2 and Volume 3.
The linux standard base that specifies how application should interact with the linux operating system (and hence includes many features required by cross operating system specifications such as posix)
The application binary interface that specifies how C and C++ should be compiled to executable files and how the operating system should interact with them.

Arachne does not assume that the base program has been compiled with a specific compiler as long as the compiler respects the standards mentioned above. However we have only be able to access to the gcc compiler and therefore Arachne has not been tested with other compilers.

9 - What is this µDyner thing mentionned in the papers?

µDyner was a previous attempt to build an aspect system. The main difference between Arachne and µDyner is that µDyner require a preparation of the base program (and hence a recompilation) while Arachne does not.

10 - Your goals on the welcome page are rather vague. Could you be more specific?

Researchers have already proposed many approaches to make application extensible and/or adaptable. Most of them however sacrifices performance and/or requires additional efforts from developers.

Our approach considers three central points:

writing a successful program is hard enough, programmers should not be bothered to consider future extensibility or adaptability issues
- For example : "The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates." (chaos report)
- There are really many papers stressing that it is difficult to write successful programs. Below are a few references;
  - Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley
  - T. Field, When BAD Things Happen to GOOD Projects, CIO, 15 Oct. 1997, pp. 55-62.
  - Reel, John , Critical Success Factors in Software Projects, IEEE Software, May/June 1999, pp18-23
There is a need for adaptable and extensible systems
- L. A. Belady, M. M. Lehman A model of large program development IBM Systems Journal Volume 15, Number 3, Page 225 (1976) stating:
  - "First Law of Program Evolution Dynamics: Law of continuing change. A system that is used undergoes continuing change until it is judged more cost effective to freeze and recreate it."
- B. Lientz, E Swanson Software Maintenance Management Addison-Wesley points out that:
  - between 50 and 70% of all effort expended on a program will be expended after it is delivered to the customer for the first time
adaptability and extensibility should not degrade performance: since we see in performance losses the reason why industry did not follow the solutions proposed by researchers.

We believe that adaptability and extensibility issues are not addressed with traditional software development tools. For example, dynamic loading:

is initiated by the program to adapt to load an adaptation/extension but the need is that the adaptation/extension chooses to be loaded by the program,
is subject to the tyranny of the dominant decomposition problem

We propose to use aspect-orientation. Aspect are woven in the program by a weaver, that is, contrary to dynamic loading, they (or a user) chooses when to load them into the program. Aspects have been devised to cope with the tyranny of the dominant decomposition problem. And finally, the aspect community seems to be concerned by performance issues.

Hence our proposition can be summarized as follow:

we use aspects to adapt/extend programs
nothing is required from program developers
- adaptation/extension are integrated at runtime on the fly on legacy systems
we pay particular attention to performance issues

11 - Do you have plans for the future?

We are very open to suggestions.

We believe that extending Arachne to support other languages could be interesting: the C language does not retain much information on the program structure and hence pointcuts are relatively limited. Compiled C++ programs in contrast contain more information on the program structure. A first application of Arachne instrumentation techniques to compiled C++ programs is discussed in Yan Chen master thesis. Extending Arachne to support C++ applications will require modifying the aspect language syntax. AspectC++ is probably the most advanced aspect language for C++ and we plan to draw our inspiration from it.

We would also like to explore the benefits brought by aspects on differents applications. Is there some kind of universal pointcut language? Should the pointcut language be domain specific? Yvonne Coady has already pointed that operating system code uses to contain many crosscutting concerns. We believe that using an operating system kernel as a weaving target to ensure its adaptability/extensibility could help to draw interesting practical conclusions on the features to be included in the Arachne language and stress the limits of our instrumentation techniques.

12 - My question is not on the list: what should I do?