Aksit, Mehmet

Bergmans, Lodewijk

Durr, Pascal

Engelen, Remco van

Gülesir, Gürcan

English

Gülesir, Gurcan

Akşit, Mehmet

van Engelen, Remco

NARCIS 

Applying AOP in an Industrial Context: An Experience Paper

University of Twente Research Information

Applying AOP in an Industrial ContextAn Experience PaperPascal Durr, Lodewijk Bergmans,Gurcan Gulesir, Mehmet AksitUniversity of Twente, The Netherlands{durr,bergmans,gulesirg,aksit}@ewi.utwente.nlRemco van EngelenASML, The Netherlandsremco.van.engelen@asml.com1. INTRODUCTIONThis position paper presents a case study we carried out in the Ide-als project. The Ideals project is a collaboration between four majorresearch institutions and an industrial partner. The research institu-tions are: the University of Twente[?], the Centrum voor Wiskundeen Informatica[?], the Technical University Eindhoven[?] and theEmbedded System Institute[?]. The industrial partner in this projectis ASML[?], from ASMLs website: “ASML is the world’s lead-ing provider of lithography systems for the semiconductor industry,manufacturing complex machines that are critical to the productionof integrated circuits or chips.”.The lithography machines that ASML develops, are large embed-ded systems. The size of the source code of this system is morethan 10 million lines of code(LOC), written in the C programminglanguage. The system is divided into several architectural layersand consists of more than 200 components. Within this context theIdeals projects aims at identifying crosscutting concerns at both im-plementation and architecture level, and to modularize these cross-cutting concerns using (new) AOP techniques.This paper presents the preliminary results of the case study wecarried out at ASML. We took a representative part of the codebase, identified the crosscutting concerns, migrated the source codeto remove the crosscutting concerns from the base code, and addaspects to incorporate the crosscutting concerns in a modular way.2. CASE STUDY SETUPFor our case study, we selected a subsystem driver component, thatis composed of 30458 lines of source code, containing 6389 con-trol and executable statements. We selected this, because it is rep-resentative in terms of crosscutting concerns. In addition, it wasrecently maintained for better modularity, which would increaseour chances to identify the “real” crosscutting concerns, i.e. not theones due to the “aging” of the component.To identify crosscutting concerns, we “manually” investigated sourcecode, and used AspectBrowser [?]. As a result, we identified sixcrosscutting concerns in the component: reflective information(e.g. listing ??, line 2), exception handling (e.g. lines 1, 3, 7,10, 11, and 14), profiling (e.g. lines 4, 5, and 13), parametertracing (e.g. lines 6 and 12), parameter checking (not shown),memory handling (not shown). Note that most of the functionscontain more core functionality than this one. Also, the crosscut-ting concern overhead is not as extreme as in this example.1 int get_roi(ROI_struct* ROI_ptr) {2 const char* func_name = "get_roi";3 int result = OK;4 timing_handle timing_hdl = NULL;5 TIMING_IN;6 trace_in(mod_data.tr_handle, func_name);7 if (result == OK){8 /* Retrieve current ROI */9 *ROI_ptr = mod_data.ROI;10 }11 LC(result, GET_ROI_FAILED_obj);12 trace_out(mod_data.tr_handle, func_name, result);13 TIMING_OUT;14 return result;15 }Listing 1: A simple getter function that exemplifies some of theidentified crosscutting concerns in a nutshell.Out of the identified crosscutting concerns, we addressed only pa-rameter tracing, profiling, and reflective information, because thesecrosscutting concerns made up for 28% of the code size, and realiz-ing them using aspects was feasible within our limited time frame.To apply AOP, we first removed the selected crosscutting concernsusing sed, which is a regular expression engine. Next, we specifiedthe aspects for the three crosscutting concerns. Finally, we used ourweaver, namely WeaveC [?], to weave the aspects.3. AOP TECHNOLOGYWeaveC is a source-to-source weaver for the C programming lan-guage, and it was developed at an earlier time in the Ideals project.It uses an XML input format and supports the following join pointsand introductions:• Function call• Function execution• Local variable introduction in a function• Global variable introduction in a file• Field introduction in a global structureThe first two elements are join points, where one can apply beforeand after advice. These join points and introductions were suffi-cient to address tracing, profiling and reflective information. Thecurrent implementation uses a grammar which can parse only pre-processed C code. There is also limited support for annotations andplug-ins.This section describes some of the issues which should be addressedfor applying an AOP approach. Although these might seem ASMLspecific. We do feel that these issues are shared by a large number,1if not all, companies. Therefore we consider this set as a collectionof common or fundamental issues that must be addressed by anyAOP mechanism, which is used in an industrial context.3.1 MigrationThe concerns we handled in this case were mostly implemented onseparate lines in the code and were easy to identify with “simple”tooling. However, migrating the tracing concern was more diffi-cult, because determining whether to trace a variable at the start orend of a function relies on the parameter’s input and output speci-fication. We implemented this by annotating which parameters areinput, output or both. Automatically generating these annotationsrequires control flow analysis and read-write analysis of the pa-rameters. The CWI is currently developing tooling to automate themigration process, i.e. to remove the crosscutting concern code, toinsert the tracing annotations and to indicate the deviations whichmust be handled manually.3.2 Availability and maturity of tooling andprocessThe current implementation and process has been developed as aproof of concept. These tools have to become industry strength,and this requires substantial investments. Using AOP for the se-lected concerns has clear benefits, but a large impact, too. The useof AOP requires a seamless integration into the development andbuild process. The tools used in these processes should be robustand mature. In an industrial development process there are usuallyspecific roles, with different responsibilities. These roles should re-main clearly separated even in the presence of aspects. If one usesAOP, there will be additional roles in the development life-cycle.Most notably, an aspect developer, a weave tool maintainer, andan integrator. The latter is responsible for the sanity of the entiresystem.3.3 Ability to switch off aspectsIt should be possible to switch on or off aspects for two reasons.Firstly, for tracking down errors, if the aspect code contains a bugthe system would still be able to compile without a specific aspect.This can only be done if the impact of the aspects is not too se-vere. For example, turning off an exception handling aspect is notfeasible as it would compromise the entire system. Secondly, formore control over the aspect application. In development versionsof the software some aspects are turned on, while in the releasesthese aspects are turned off. Or, if some component is called often,Tracing might need to be turned off for runtime efficiency. As mostidentified aspects are cleanly separated from the base code, thesecan be turned off, if required. However, if there are base-aspect oraspect-aspect dependencies this is not trivial.3.4 Understandability (mental model)ASML uses the C programming language, hence switching to AOPis considered to be a real issue. There is, in AOP, a clear separationbetween aspect developers and core developers. Core developersstill want to understand what goes on behind the scenes, as theycan be a bit wary of new techniques, and want to verify the wovencode.3.5 Compile-time & Run-time performanceIn large systems with many developers and many dependencies be-tween components, the build performance can be quite substantial.As the throughput at runtime must be guaranteed, a runtime perfor-mance hit is usually not acceptable. A static weaving approach isthus more attractive. A compile-time performance hit is usually ac-ceptable as long as the performance hit is not several factors higherthan a regular build or the hit is exponential with the number of joinpoints.3.6 Ability to DebugDebugging a program with aspects is also considered to be an is-sue. Especially, if an error occurs who is responsible for fixing thiserror? First of all this requires determining whether the error is inthe aspect code, in the core code or in the combination. As thecore developers may not be aware of aspects, they may not want tosee the code with the aspects applied. However, when debuggingthe total system, one needs to be aware of the aspects. We cameup with the following options: debug with the inserted code, debugwith inserted code hidden, and debug normally and while executingthe inserted code jump to the aspect definition. In our case studywe implemented the second option.4. EVALUATION AND BENEFITSThis section will briefly explain the results we achieved with ourcase study. Most of these are considered to be the key motivationsfor using AOP. We provide these in the context of the case study.4.1 Statement reductionAs stated previously, our experiment was carried out on a compo-nent of about 6K LLOC. We use the term LLOC to indicate alllogical lines, thus excluding white space and comments. In ourexperiment, we achieved a reduction of 26% of LLOC, comparedto the orignal code. In our case study, we only implemented threeaspects. If we would also address parameter checking and errorhandling, the reduction would be up to 50%. The migration path,especially for the error handling concern, is more difficult as theerror handling code is tangled with the base code.4.2 Local deviationsThe solution we proposed still allows for local deviations. Forexample, there are functions which are called often and for thesefunctions tracing is turned off. There are also low level compo-nents which do not trace, as these are active before the logging andtracing component is initiated. Although we do not endorse thesedeviations, one can implement these deviations with the use of an-notations and a more powerful pointcut description language. Mostaspects discussed here implement coding guidelines. These shouldtherefore be enforced and applied uniformly. For this reason, theusage of local deviations has to be constrained. However, thereare situations where local deviations are necessary from a businesspoint of view.4.3 Better software structureThis benefit has been stated as one of the corner stone benefits ofAOP and separation of concerns in general. The pointcut and ad-vice mechanisms provides an easy way to deal with changing cod-ing guidelines. The benefit of AOP was clearly visible when weapplied the profiling aspect on a different component (without pro-filing) within 10 minutes. Although this flexibility, in advice, canpartly be achieved by using macros in C. Macros do not offer apointcut like mechanism, one always has to import or include themacros explicitly in each file and place the macro calls in the cor-rect locations.5. CONCLUSION2In this paper we presented the preliminary results of a case studywhich we carried out with ASML. Our goal with the case studywas to show how AOP can increase the software structure, reducethe code size and thus the development and maintenance effort.We took a small but representative component and used AOP tech-niques to address crosscutting concerns. We clearly showed that fora few concerns the benefits are quite substantial. ASML is currentlyinvestigating the use of AOP within their development process.This work has been carried out as part of the Ideals project underthe responsibility of the Embedded Systems Institute. This projectis partially supported by the Netherlands Ministry of Economic Af-fairs under the Senter program.3

Applying AOP in an Industrial Context:An Experience Paper

Applying AOP in an Industrial Context: An Experience Paper

Abstract

Similar works

Full text

Available Versions

NARCIS

University of Twente Research Information