Dr. Dobb's Journal - September 2008 - (Page 57)

d09kilch_p3db 7/17/08 8:23 AM Page 57 • New methods, which are used for overflow reporting (unless a callback is given) and for overflow detection (unless the user chooses to inline the tests, which makes the code faster and often bigger). For each instrumented class, the corresponding memory footprint of these additions typically amounts to a constant of less than 5KB, plus a couple of bytes for each arithmetic operation. To give an idea, when activating every possible check, the Java2Demo.jar program grows from 400KB to 625KB. It is a bit harder to predict the slowdown incurred by COJAC, because it depends on factors like the hardware and OS, the JVM version and parameters (with/without JIT), or the proportion of integer arithmetic operations in the instrumented code. We measured the slowdown on a reasonable configuration for the four operators on ints. The overhead per arithmetic operation ranges from 20 percent (for idiv), to 950 percent (for imul). When inlining the detection method, this overhead is reduced and reaches between 10 percent (for idiv) and 580 percent (for iadd). As a typical Java program does other things than integer operations, we can expect that the runtime will roughly grow by a factor of two (as we observed with sorting algorithms). This is an important overhead, but similar to other means used for discovering bugs (think about using memory checkers like Valgrind in C/C++). • Floating-point operations do not suffer from overflow, but also have pitfalls; sometimes it would be useful to discover that a number did not change after the addition of a nonzero term or the product with a nonone factor. It would be easy to extend COJAC to report such situations. COJAC is designed to be simple and robust, and this causes some inherent limitations: (a) • Compile-time evaluated expressions are not detected. The compiler evaluates expressions such as (3*Integer.MAX_VALUE), and only the result is stored in the bytecode. • The instrumentation could potentially be confusing for the debugger and other tools that exploit the correspondence between source code and bytecode (e.g. a profiler). • Because we didn’t want to add a new class in the instrumented code, the public static double arraySum(double [] t) { double sum=0.0; for(int i=0; i<t.length; i++) sum+=t[i]; return sum; } (b) public static arraySum(double[]):double L0 (0) LINENUMBER 11 L0 DCONST_0 DSTORE 1: sum L1 (3) LINENUMBER 12 L1 ICONST_0 ISTORE 3: i L2 (6) GOTO L3 L4 (8) LINENUMBER 13 L4 DLOAD 1: sum ALOAD 0: t ILOAD 3: i DALOAD DADD DSTORE 1: sum L5 (15) LINENUMBER 12 L5 IINC 3: i 1 L3 (17) ILOAD 3: i ALOAD 0: t ARRAYLENGTH IF_ICMPLT L4 L6 (22) LINENUMBER 14 L6 DLOAD 1: sum DRETURN L7 (25) LOCALVARIABLE t double[] L0 L7 0 LOCALVARIABLE sum double L1 L7 1 LOCALVARIABLE i int L2 L6 3 MAXSTACK = 4 MAXLOCALS = 4 (c) Perspectives Using the ASM library, COJAC was not really hard to implement. It nevertheless opens some interesting perspectives: • It is straightforward to implement a new classloader that performs on-the-fly instrumentation. • Java is not the only programming language that produces code for the JVM. Thus, COJAC is expected to be suitable for other languages equipped with a bytecode translator, like Python or Ruby. • COJAC could be packaged as an Eclipse plug-in that automatically performs instrumentation on entire projects. Similarly, it would of course be possible to integrate the functionality as a Java compiler option (maybe considered in a next release of Java?). MethodVisitor mv; mv = cw.visitMethod(ACC_PUBLIC + ACC_STATIC, "arraySum", "([D)D", null, null); mv.visitCode(); Label l0=new Label(), l1=new Label(), l2=new Label(), ; mv.visitLabel(l0); mv.visitLineNumber(11, l0); mv.visitInsn(DCONST_0); mv.visitVarInsn(DSTORE, 1); mv.visitLabel(l1); mv.visitLineNumber(12, l1); mv.visitInsn(ICONST_0); mv.visitVarInsn(ISTORE, 3); mv.visitJumpInsn(GOTO, l3); mv.visitLabel(l4); mv.visitLineNumber(13, l4); mv.visitVarInsn(DLOAD, 1); mv.visitVarInsn(ALOAD, 0); mv.visitVarInsn(ILOAD, 3); mv.visitInsn(DALOAD); mv.visitInsn(DADD); mv.visitVarInsn(DSTORE, 1); mv.visitLabel(l5); mv.visitLineNumber(12, l5); mv.visitIincInsn(3, 1); mv.visitLabel(l3); mv.visitVarInsn(ILOAD, 3); mv.visitVarInsn(ALOAD, 0); mv.visitInsn(ARRAYLENGTH); mv.visitJumpInsn(IF_ICMPLT, l4); mv.visitLabel(l6); mv.visitLineNumber(14, l6); mv.visitVarInsn(DLOAD, 1); mv.visitInsn(DRETURN); mv.visitLabel(l7); mv.visitLocalVariable("t", "[D", null, l0, l7, 0); mv.visitLocalVariable("sum", "D", null, l1, l7, 1); mv.visitLocalVariable("i", "I", null, l2, l6, 3); mv.visitMaxs(4, 4); mv.visitEnd(); Example 2: (a) Source code, (b) bytecode, (c) ASMifier output. September 2008 l www.ddj.com l Dr. Dobb’s Journal 57 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - September 2008

Dr. Dobb's Journal - September 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook A Conversation With Erik Demaine Application Lifecycle Management Meets Model-Driven Development Building a Robust Development Environment Real Users Really Matter Matching Wildcards: An Algorithm The Android Mobile Phone Platform Managing Application Thread Use Signalling Integer Overflows in Java .NET Development & the IBM WebSphere Portal Server The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.