Advice Weaving in ÉNFASIS

Transcription

1 2010 Electronics, Robotics and Automotive Mechanics Conference Advice Weaving in ÉNFASIS Ulises Juárez-Martínez Division of Research and Postgraduate Studies Instituto Tecnológico de Orizaba 94320, Veracruz, México Giner Alor-Hernández Division of Research and Postgraduate Studies Instituto Tecnológico de Orizaba 94320, Veracruz, México Abstract This paper describes the implementation of advice weaving in ÉNFASIS. Énfasis is a domain-specific framework designed to program fine-grained aspects and apply crosscutting on local variables. Applications of fine-grained aspects include data flow analysis, program comprehension, assertions, code coverage, among others. The ÉNFASIS framework uses bytecode instrumentation to weave statically pieces of advice. We describe how ÉNFASIS join points are mapped to specific regions of bytecode, how to implement advice, and how to expose the pointcut context without using arguments between pointcuts and pieces of advice, a novel capability in our framework not available in AspectJ-like languages. Keywords-aspect-orientation, bytecode, compilers, Énfasis, local variable crosscutting, weaving I. INTRODUCTION Aspect-Oriented Programming [1] is a paradigm that allows concerns (system attributes) modularization. Concerns like persistence, performance, logging, and concurrency require some class or instance members to perform its function. Likewise, concerns such as testing, tracing, program comprehension, program visualization, assertions, monitoring, and complexity require finer elements of a program, specifically local variables. The last concerns are not supported by AspectJ-like languages and some approaches address this problem [2], [3], [4], [5], and some authors justify fine granularity from a broader perspective [6], [7], [8], [9], even new join point models [10], [11]. ÉNFASIS [12] is a Java framework for defining finegrained aspects. The framework supports static and dynamic crosscutting. The static crosscutting allows to change the class structure to add new members, including constructors. The dynamic crosscutting changes the behavior of applications and it is used to quantify local variables. ÉNFASIS introduces path expressions, a novel concept to identify local variables in specific parts of a method. In this paper we describe the advice mechanism implemented by ÉNFASIS for ensuring that both code of classes and aspects work in a coordinated way. The paper covers only bytecode instrumentation for implementing advice and pointcut context. The locus in ÉNFASIS are local variable shadows, which are requered elements to identify join points. Additional details and applications can be found in [13], [12], [14], [15]. II. ÉNFASIS IN A NUTSHELL A HelloWorld example is suitable to be able to introduce quickly most of the concepts that ÉNFASIS provides and discuss the implications that are behind of bytecode instrumentation as part of weaving process. The HelloWorld class is the following one: public class HelloWorld { public static void main (String[] args) { double d = Math.random(); System.out.println(d); } } A possible exit of the program execution could be: In this example, local variable d is available in the whole body of the method main(). Let s consider local variable monitoring concern where we need to be able to show a message before printing its value. The message will be composed by a string and the same value of the variable. The aspect for this purpose is shown next. 1 public aspect HelloWorldEnfasis { 2 pointcut p(): getlocal (void 3 HelloWorld.main( 4 String[])/double d); 5 before(): p() { 6 System.out.println("Local 7 variable: " + d); } } As we can see, ÉNFASIS uses an AspectJ-like syntax and the pointcut primitive is getlocal. Local variable quantification is associated with method signatures (getlocal argument, lines 2 to 4). The slash indicates the local variable scope, in this case, its location within all method body. Advice code can use fields and variables available at the join point interception. The advice uses local variables without specify any arguments to expose the context. This is legal in ÉNFASIS and it is a novel capability in our framework not available in AspectJ-like languages. In some cases, thisjoinpoint reflexive variable is avoided. The weaving process modifies the bytecode changing the program behaviour. A possible exit could be: /10 $ IEEE DOI /CERMA

2 Local variable: III. HELLOWORLD BYTECODE Local variable join points are associated with events smaller than a sentence, thus it is not possible to quantify using source code, in this case we need to know the details behind of bytecode. The following fragment of bytecode shows the original method main() for HelloWorld and the local variable table (LVT). public static void main(string[]); Stack=3, Locals=3, Args_size=1 0: invokestatic [Math.random:()D] 3: dstore_1 7: dload_1 8: invokevirtual [PrintStream.println:(D)V] 11: return LocalVariableTable: Start Length Slot Name Signature args [String; d D After weaving, ÉNFASIS changes the bytecode as follows. public static void main(string[]); Stack=5, Locals=3, Args_size=1 0: invokestatic [Math.random:()D] 3: dstore_1 7: getstatic [System.out:PrintStream;] 10: new [StringBuffer] 13: dup 14: invokespecial [StringBuffer."<init>":()V] 17: ldc ["Advising a local variable!"] 19: invokevirtual [StringBuffer.append: (String;)StringBuffer;] 22: dload_1 23: invokevirtual [StringBuffer.append: (D)StringBuffer;] 26: invokevirtual [StringBuffer.toString: ()String;] 29: invokevirtual [PrintStream.println: (String;)V] 32: dload_1 33: invokevirtual [PrintStream.println:(D)V] 36: return LocalVariableTable: Start Length Slot Name Signature args [String; d D Addresses 0, 3 and 4 are the same from the original bytecode. Addresses 4, 32, and 33, were generated by the original sentence System.out.println(d);. Now they are separated by another set of instructions (addresses 7 to 29) which were inserted by the aspect. Finally, addresses Type Shadow getlocal aload, dload, fload, iload, lload setlocal astore, dstore, fstore, istore, lstore, iinc Table I STATIC SHADOWS FOR LOCAL VARIABLES. 32 to 36 are the original instructions of class HelloWorld. Note that addresses 4 and 7 are two consecutive invocations to place the same field System.out in the stack, which will never be generated by traditional compilation of Java. IV. LOCAL VARIABLE SHADOWS The weaving mechanism in ÉNFASIS uses static shadows for local variables, which are represented by two families of instructions called load and store. load instructions allow to place a local variable in the operand stack whereas store instructions store operands in a local variable. The set of shadows are shown in table I. Each group of instructions is preceded by a letter that represents a primitive data type or a reference: a is an object reference. d is a double value. f is a float value. i represents a primitive data type: boolean, byte, short and int. l is a long value. And each instruction can appear in two variants: xload_<n> and xload <n>. xstore_<n> and xstore <n>. where n is an index in the local variable array, the bottom dash ( ) is used for indexes from 0 to 4, whose operand is implicit and x is someone of the letters that represent the data type of the variable. Also, it is considered the instruction iinc that increments a constant value for a local variable. This instruction modifies directly the value of the variable in the stack, thus the static shadow identified represents only an assignment operation (setlocal). The wide instruction modifies the behavior of another instruction to allow reading additional bytes that represent the data. This instruction does not represent a shadow, but it must be considered to identify correctly the bytes involved in the instruction. V. ANALYSIS OF SHADOWS In order to identify correctly the join points using static shadows, it is necessary to know in detail how the bytecode is generated with the operators that the language provides. The implementation of ÉNFASIS does not consider operations that involve bitwise operators. For this analysis Java 1.6 was used. 91

3 A. Java operators The first case is the generation of bytecode for increment (++), assignment with increment (+=) and assignment (=) operators. The basic operation is to increase by 1 an integer (primitive). We have three options: i = i + 1; i++; i += 1; The bytecode generated by these options are shown next: 0: bipush 10 [value 10] 2: istore_1 [store in slot 1] 3: iinc 1, 1 [add 1 to value in slot 1] 6: return The second case is when a variable is increased by a big number. i = i ; i += 50000; The bytecode generated for both cases is the next one: 0: bipush 10 [value 10] 2: istore_1 [store in slot 1] 3: iload_1 [load value from slot 1] 4: ldc [int 50000] 6: iadd [add] 7: istore_1 [store result in slot 1] To understand how the generated instructions change when the size of the constant changes, let s consider the following: In the range of 1 byte (-128 to 127) the generated instruction is iinc. In the range of 2 bytes (short) the instruction is iinc_w. In the range of 4 bytes (int) the generated instructions are iload, ldc, iadd and istore. In the range of 8 bytes (long) the generated instructions are lload, ldc2_w, ladd and lstore. If the local variables are byte or short data types, then iinc instructions are not generated. Instead, explicit iload and istore instructions are generated, with additional instructions like i2b and i2s for the required conversions. It is important to consider the behavior when we use wrapper classes. Byte i = new Byte((byte)0); i++; 0: new [Byte] 3: dup 4: iconst_0 5: invokespecial [Byte."<init>":(B)V] 8: astore_1 9: aload_1 10: invokevirtual [Byte.byteValue:()B] 13: iconst_1 14: iadd 15: i2b 16: invokestatic [Byte.valueOf:(B)Byte;] 19: astore_1 Likewise, when we use autoboxing the behaviour is: Byte i = 0; i++; 0: iconst_0 1: invokestatic [Byte.valueOf:(B)Byte;] 4: astore_1 5: aload_1 6: invokevirtual [Byte.byteValue:()B] 9: iconst_1 10: iadd 11: i2b 12: invokestatic [Byte.valueOf:(B)Byte;] 15: astore_1 The generation of code is similar for Short, Integer and Long data types, except by intermediate instructions for conversions. The aload and astore instructions are the same for all the cases. For boolean and char data types and their wrappers, the same rules apply. The float and double data types and their wrappers generate fload, fstore, dload, dstore, aload and astore instructions. The last two instructions apply for any object, in this way read and write join points are easily identifiable. B. Hidden shadows: iinc instruction A sentence like i = i + 25; generates the bytecode instruction iinc 8 = 25. iinc instruction is used to directly increase the stack of local variables, the operand stack is not used to perform operations. Taking in account this, iinc represents a natural join point only for write operations. In ÉNFASIS, iinc instruction has been called a hidden static shadow because it does not allow the explicit identification of join points for read and write operations. An alternative is to transform the iinc instruction in its equivalent load and store instructions. Let s consider the bytecode instruction iinc It can be transformed in: iload 8 bipush 25 iadd istore 8 In this way, the join point is exposed with shadows for read and write join points. It is important to note that this type of transformation generates an overload in the stack operations. The justification is based in the fact that the small 92

4 increments generate bad quantification using getlocal designator. 1) Support to expose hidden shadows: ÉNFASIS uses a refactoring mechanism to translate instructions iinc and iinc_w (wide followed by iinc) in its equivalent group of instructions: load, the constant, the involved operator and store. All the indexes, pc, addresses an entries in the local variable and line number tables are updated automatically. Therefore, there is no loss of references between the modified bytecode and its source code. Current implementation of ÉNFASIS supports exposing hidden shadows by an explicit option in the compiler. C. Local constants (final) A local variable could be declared as a constant. A final variable has implications in the context of hidden shadows. The following code shows an example with a variable. public void m() { int i = 8000; System.out.println(i); } public void m(); Stack=2, Locals=2, Args_size=1 0: sipush : istore_1 7: iload_1 8: invokevirtual [PrintStream.println:(I)V] 11: return The following code shows the previous version with the same variable, but declared as final. public void m() { final int i = 8000; System.out.println(i); } public void m(); Stack=2, Locals=2, Args_size=1 0: sipush : istore_1 7: sipush : invokevirtual [PrintStream.println:(I)V] 13: return Note that the instruction at address 7 places directly the constant without calling to the instruction iload_1. The exception to this situation happens when the value of the constant comes as a result of a method invocation or it is a value from another variable or field. In this case, load instructions will be generated and now it is possible to identify join points. The next example shows this situation. public void m() { final int i = (int)(math.random()*8000); System.out.println(i); } public void m(); Stack=4, Locals=2, Args_size=1 0: invokestatic [Math.random:()D] 3: ldc2_w [double d] 6: dmul 7: d2i 8: istore_1 9: getstatic [System.out:PrintStream;] 12: iload_1 13: invokevirtual [PrintStream.println:(I)V] 16: return iload_1 instruction at address 12 recovers the constant i. At bytecode level there is no mechanism to identify a local constant, unlike fields where a final declaration could be found. An option to solve this problem is detecting final declarations at source code. Current version of ÉNFASIS does not support this kind of hidden shadows. VI. ADVICE IMPLEMENTATION This section describes the details for advice implementation showing the bytecode transformations required by ÉNFASIS. A. before advice Let s consider the assignment m = 10;. The compiler generates the bytecode: 18: bipush 10 20: istore_1 A join point could be associated with address 20, with an istore instruction (in this case variable m). before advice implementation requires to refactor the bytecode inserting its instructions as follows: 18: bipush 10 20: getstatic [System.out] 23: ldc ["before a local variable!"] 25: invokevirtual [PrintStream.println:(String;)V] 28: istore_1 B. after advice after advice implementation is analogous to before advice. 18: bipush 10 20: istore_1 21: getstatic [System.out] 24: ldc ["after a local variable!"] 26: invokevirtual [PrintStream.println:(String;)V] C. around advice around advice allows to change and replace the behavior of the application. For local variables, the substitution has the effect of changing the original value of the variable for read and write join points, plus the additional execution of code. 93

5 To achieve this, ÉNFASIS inserts instructions in order to replace the value of the variable just before calling it or storing it. If the advice contains code to execute, it is inserted first, next the instructions for replacement. 1) proceed method: This method allows to get the original value of the variable. The next example shows how to use both around advice and proceed() method. 1 public aspect AroundAspect { 2 double around(): getlocal(void 3 Class.main(..)/double i) { 4 System.out.println(thisJoinPoint); 5 return 88.88; } } Applying the AroundAspect to HelloWorld example (see section 2), the program prints: getlocal(void Class.main(String[])/double i) VII. DISCUSSION Most of cases, the instrumented bytecode does not have correspondence with the high-level statements because insertions can be done in local variable shadows such as method arguments, loops or inside expressions. The join point model can locate variables inside for, enhanced for, while and do-while loops as well as if-else statements. The weaving process inserts all pieces of advice wherever a shadow is located (the code is in-lined). After the insertion, the instructions are consumed in order to get the same state before the insertion. This approach has the advantage of being highly efficient. ÉNFASIS uses strings and wildcards to specify pointcut quantification, but this establishes lexical dependencies generating pointcut fragility. VIII. FUTURE WORK Current ÉNFASIS language supports only getlocal and setlocal pointcut designators with a complete advice mechanism. We are considering to extend the language to support all capabilities of the framework. Another improvement is to support switch statements. IX. RELATED WORK Josh [2] uses Javassist to implements and AspectJ-like language with an extensible pointcut language. The extensions are limited to Javassist capabilities, but it does not support local variable crosscutting. This work is related to ÉNFASIS because its framework uses an extension of Javassist to identify shadows and transform bytecode instructions. Bugdel [5] is an aspect-oriented system for debugging. It provides two pointcut designators: line (for line numbers) and alllines (method name). thisjoinpoint variable is extended with line and variables to provide information about local variables available at a specific line of source code. In this sense, ÉNFASIS take a step further with a more precise pattern matching mechanism to select local variables and with a join point model for many application areas. LogicAJ2 [4] introduces the concept of fine-grained genericity. Based on static analysis and logic-meta variables, it is possible to construct any new pointcut designators such as getl and setl for local variables. However, those designators are not capable for selecting specific join points for local variables neither show source code information. X. CONCLUSIONS This paper has presented the advice weaving implementation in the ÉNFASIS framework. It uses byte code instrumentation to insert advice behaviour, identify shadows, expose hidden shadows, and use pointcut context without exposing its arguments. Details about how to implement advice and how to transform instructions were presented. Advice weaving for local variables is very important to encapsulate concerns related to program verification. This approach is not currently supported by any other aspect language. ACKNOWLEDGMENT This work is supported by the General Council of Superior Technological Education of México (DGEST). Additionally, this work is sponsored by the National Council of Science and Technology (CONACYT). REFERENCES [1] G. Kiczales, J. Irwin, J. Lamping, J.-M. Loingtier, C. V. Lopes, C. Maeda, and A. Mendhekar, Aspect-Oriented Programming, ACM Comput. Surv., vol. 28, [2] S. Chiba and K. Nakagawa, Josh: An Open AspectJ-like Language, in Proceedings of the 3rd International Conference on Aspect-Oriented Software Development (AOSD 04), Lancaster, UK, March [3] B. Harbulot and J. R. Gurd, A join point for loops in AspectJ, in Foundations of Aspect-Oriented Languages workshop, AOSD, R. E. Filman, Ed. ACM, 2006, pp [4] T. Rho, G. Kniesel, and M. Appeltauer, Fine-Grained Generic Aspects, in Foundations Of Aspect-Oriented Languages workshop, Bonn, Germany, March [5] Y. Usui and S. Chiba, Bugdel: an aspect-oriented debugging system, in Proceedings of the 12th Asia-Pacific Software Engineering Conference (APSEC 05), Taipei, Taiwan, December [6] C. Kastner and S. Apel, Granularity in Software Product Lines, in Proceedings of the 30th International Conference on Software Engineering (ICSE), Leipzig, Germany, May [7] J. Park and S. Hong, Customizing Real-Time Operating Systems with Aspect-Oriented Programming Framework, in Separation of Concerns Design Conference, 2003, pp

6 [8] H. Rajan and K. Sullivan, Generalizing AOP for Aspect- Oriented Testing, in In the proceedings of the Fourth International Conference on Aspect-Oriented Software Development (AOSD 2005), Chicago, IL, USA., March [9] N. Ubayashi, H. Masuhara, and T. Tamai, An AOP Implementation Framework for Extending Join Point Models, in Workshop on Reflection, AOP, and Meta-Data for Software Evolution, Oslo, June 2004, pp [10] N. M. Ali and A. Rashid, A State-based Join Point Model for AOP, in Proceedings of the 1st ECOOP Workshop on Views, Aspects and Role (VAR 05), in 19th European Conference on Object-Oriented Programming, [11] Y. Endoh, H. Masuhara, and A. Yonezawa, Continuation Join Points, in Foundations of Aspect-Oriented Languages Workshop at AOSD, March 2006, pp [12] U. Juárez-Martínez and J. O. Olmedo-Aguirre, ÉNFASIS: A Model for Local Variable Crosscutting, in In proceedings of the 23rd Annual ACM Symposium on Applied Computing (SAC). Cear, Brazil: University of Fortaleza (UNIFOR) and Federal University of Cear (UFC), March , pp [13], A Join Point Model for Fine-Grained Aspects, in Proceedings of 2nd. European Computing Conference, Malta, September [14], Run-Time Assertion Checking with ÉNFASIS, Computación y Sistemas Journal, vol. 13, no. 4, [15] U. Juárez-Martínez, G. Alor-Hernández, and R. Posada- Gómez, An Aspect-Oriented Approach for Assertion Verification, in In Proceedings of the First International Conference on Advances in System Testing and Validation Lifecycle (VALID), Porto, Portugal, September 2009, pp