infomancers-collections - Project Hosting on Google Code

Older Aug 13, 2009 issue 3 (Ant build not cross platform) Blocked on changed by aviad.in...@gmail.com - Aug 08, 2009 yielder-0.3.0.jar (Yielder binaries, version 0.3.0) file uploaded by aviad.in...@gmail.com - Labels: Featured Type-Agent OpSys-All Labels: Featured Type-Agent OpSys-All Aug 08, 2009 r122 (Added ASM-3.1 binary/source and ASM-3.0 source.) committed by aviad.in...@gmail.com - Added ASM-3.1 binary/source and ASM-3.0 source. Added ASM-3.1 binary/source and ASM-3.0 source. Aug 08, 2009 issue 13 (WONT work for simple generator) Status changed by aviad.in...@gmail.com - Sorry for the delay, it took a long time to get back to the yielder project. This seems like a really odd bug. In any case, I rewrote the second example in a unit test, see class Issue13 in the trunk version. This works now. Please verify that it does. Status: Fixed Sorry for the delay, it took a long time to get back to the yielder project. This seems like a really odd bug. In any case, I rewrote the second example in a unit test, see class Issue13 in the trunk version. This works now. Please verify that it does. Status: Fixed Aug 08, 2009 r121 (Added google-code issue 13 test and verified success.) committed by aviad.in...@gmail.com - Added google-code issue 13 test and verified success. Added google-code issue 13 test and verified success. Aug 08, 2009 issue 12 (Exceptions not working) commented on by aviad.in...@gmail.com - Tests still don't pass. After changing the modification technique, there is a need for special handling of exception handler areas. Tests still don't pass. After changing the modification technique, there is a need for special handling of exception handler areas. Aug 08, 2009 issue 11 (Cannot call instance methods of local variables) Status changed by aviad.in...@gmail.com - Although late, this has been fixed in the current trunk version. See the Issue11 JUnit class. Status: Fixed Although late, this has been fixed in the current trunk version. See the Issue11 JUnit class. Status: Fixed Aug 08, 2009 r120 (Added google-code issue 11 test and verified success.) committed by aviad.in...@gmail.com - Added google-code issue 11 test and verified success. Added google-code issue 11 test and verified success. Aug 08, 2009 r119 (All tests except for exception handling work now. Added som...) committed by aviad.in...@gmail.com - All tests except for exception handling work now. Added some exception-stack handling but its still tricky. All tests except for exception handling work now. Added some exception-stack handling but its still tricky. Aug 08, 2009 issue 14 (Boolean array set/get code generation not optimal) reported by aviad.in...@gmail.com - Since the opcode for set/get value to/from a boolean array is the same as it is for the byte array (BASTORE/BALOAD), and since the boolean array is saved as a java.lang.Object slot, and since there is no real way to tell which array it is from the Opcode. So the origin code of: // method vars: boolean[] arr = ...; int idx = ...; // code: stack <- arr[idx]; Results in code that does essentially this: // vars are promoted to member slots: Object arr = this.slot$1; int idx = this.slot$2; boolean c; // need to know the type of array: if (arr.getClass().getComponentType().equals(Byte.TYPE)) { stack <- java.lang.reflect.Array.getByte(arr, idx); else { stack <- java.lang.reflect.Array.getBoolean(arr, idx); } This could be improved by looking-ahead and checking is the type of the assigned variable, and then create the correct CHECKCAST bytecode (to [Z or [B), or by keeping metadata on the slots so that we could tell what was their original type, even after merger with other types, to better deduce bytecode creation. Since the opcode for set/get value to/from a boolean array is the same as it is for the byte array (BASTORE/BALOAD), and since the boolean array is saved as a java.lang.Object slot, and since there is no real way to tell which array it is from the Opcode. So the origin code of: // method vars: boolean[] arr = ...; int idx = ...; // code: stack <- arr[idx]; Results in code that does essentially this: // vars are promoted to member slots: Object arr = this.slot$1; int idx = this.slot$2; boolean c; // need to know the type of array: if (arr.getClass().getComponentType().equals(Byte.TYPE)) { stack <- java.lang.reflect.Array.getByte(arr, idx); else { stack <- java.lang.reflect.Array.getBoolean(arr, idx); } This could be improved by looking-ahead and checking is the type of the assigned variable, and then create the correct CHECKCAST bytecode (to [Z or [B), or by keeping metadata on the slots so that we could tell what was their original type, even after merger with other types, to better deduce bytecode creation. Aug 08, 2009 r118 (Fixed ArrayLoader to not go too high when stack-crawling. ) committed by aviad.in...@gmail.com - Fixed ArrayLoader to not go too high when stack-crawling. Fixed ArrayLoader to not go too high when stack-crawling. Aug 07, 2009 r117 (Fixed off isJump bug where ALOAD would appear +1 below the j...) committed by aviad.in...@gmail.com - Fixed off isJump bug where ALOAD would appear +1 below the jump and not directly below it. Fixed off isJump bug where ALOAD would appear +1 below the jump and not directly below it. Aug 07, 2009 r116 (Created some more trouble by trying to fix things late at ni...) committed by aviad.in...@gmail.com - Created some more trouble by trying to fix things late at night... :/ Seriously though: Tried to position the ALOAD 0 in the correct position, taking into account the TABLESWITCH, LABELs, and non-changing bytecodes... Created some more trouble by trying to fix things late at night... :/ Seriously though: Tried to position the ALOAD 0 in the correct position, taking into account the TABLESWITCH, LABELs, and non-changing bytecodes... Aug 07, 2009 r115 (Switched enhancing to go bottom-up. Nothing works now, but i...) committed by aviad.in...@gmail.com - Switched enhancing to go bottom-up. Nothing works now, but it seems to be a preferred technique.. Just need to re-arrange all the enhancers. Switched enhancing to go bottom-up. Nothing works now, but it seems to be a preferred technique.. Just need to re-arrange all the enhancers. Aug 07, 2009 r114 (Fixed stack-crawling to stop at labels.) committed by aviad.in...@gmail.com - Fixed stack-crawling to stop at labels. Fixed stack-crawling to stop at labels. Apr 05, 2009 r113 (Fixed treatment to going back the stack.) committed by aviad.in...@gmail.com - Fixed treatment to going back the stack. Fixed treatment to going back the stack. Apr 05, 2009 r112 (Import updates.) committed by aviad.in...@gmail.com - Import updates. Import updates. Apr 05, 2009 r111 (Improved testability.) committed by aviad.in...@gmail.com - Improved testability. Improved testability. Apr 05, 2009 r110 (Added support for multi-a-new-array in code stack handler.) committed by aviad.in...@gmail.com - Added support for multi-a-new-array in code stack handler. Added support for multi-a-new-array in code stack handler. Apr 05, 2009 r109 (Made code stack handler more efficient and support all opcod...) committed by aviad.in...@gmail.com - Made code stack handler more efficient and support all opcodes (except MULTIANEWARRAY) Made code stack handler more efficient and support all opcodes (except MULTIANEWARRAY) Apr 04, 2009 r108 (Added unbox/rebox support to iinc enhancer.) committed by aviad.in...@gmail.com - Added unbox/rebox support to iinc enhancer. Added unbox/rebox support to iinc enhancer. Apr 04, 2009 r107 (Added array store enhancer.) committed by aviad.in...@gmail.com - Added array store enhancer. Added array store enhancer. Apr 04, 2009 r106 (Added unboxing support to load enhancer.) committed by aviad.in...@gmail.com - Added unboxing support to load enhancer. Added unboxing support to load enhancer. Apr 04, 2009 r105 (Added boxing support to store enhancer.) committed by aviad.in...@gmail.com - Added boxing support to store enhancer. Added boxing support to store enhancer. Apr 04, 2009 r104 (Added treatment for method invocations.) committed by aviad.in...@gmail.com - Added treatment for method invocations. Added treatment for method invocations. Apr 04, 2009 r103 (Fixed badly treated long and object arrays in ArrayLoad.) committed by aviad.in...@gmail.com - Fixed badly treated long and object arrays in ArrayLoad. Fixed badly treated long and object arrays in ArrayLoad. Apr 04, 2009 r102 (Added treatment for ldc.) committed by aviad.in...@gmail.com - Added treatment for ldc. Added treatment for ldc. Apr 04, 2009 r101 (Added treatment for method invocation in stack calculations.) committed by aviad.in...@gmail.com - Added treatment for method invocation in stack calculations. Added treatment for method invocation in stack calculations. Apr 04, 2009 r100 (Added treatment for yieldBreak; more tests passing.) committed by aviad.in...@gmail.com - Added treatment for yieldBreak; more tests passing. Added treatment for yieldBreak; more tests passing. Apr 04, 2009 r99 (Arraylength enhancer added. Some array tests working.) committed by aviad.in...@gmail.com - Arraylength enhancer added. Some array tests working. Arraylength enhancer added. Some array tests working. Apr 04, 2009 r98 (Added array load enhancer. Array tests still not working.) committed by aviad.in...@gmail.com - Added array load enhancer. Array tests still not working. Added array load enhancer. Array tests still not working. Apr 04, 2009 r97 (Some of the tests pass!) committed by aviad.in...@gmail.com - Some of the tests pass! Some of the tests pass! Apr 03, 2009 r96 (Made the test configuration part of the project file.) committed by aviad.in...@gmail.com - Made the test configuration part of the project file. Made the test configuration part of the project file. Apr 03, 2009 r95 (Added state keeper to tree version. Still not working.) committed by aviad.in...@gmail.com - Added state keeper to tree version. Still not working. Added state keeper to tree version. Still not working. Apr 03, 2009 r94 (Started work on yieldReturn enhancer. Not working.) committed by aviad.in...@gmail.com - Started work on yieldReturn enhancer. Not working. Started work on yieldReturn enhancer. Not working. Apr 03, 2009 r93 (Replacement of xLOAD now works with tree-api.) committed by aviad.in...@gmail.com - Replacement of xLOAD now works with tree-api. Replacement of xLOAD now works with tree-api. Apr 03, 2009 r92 (Replacement of xSTORE now works with tree-api.) committed by aviad.in...@gmail.com - Replacement of xSTORE now works with tree-api. Replacement of xSTORE now works with tree-api. Apr 03, 2009 r91 (Added some parameters to agent to allow dynamic selection be...) committed by aviad.in...@gmail.com - Added some parameters to agent to allow dynamic selection between tree and non-tree. Added some parameters to agent to allow dynamic selection between tree and non-tree. Apr 03, 2009 r90 (Started the tree-api development.) committed by aviad.in...@gmail.com - Started the tree-api development. Started the tree-api development. Apr 03, 2009 r89 (Refactored the core of the yielder functionality out, to all...) committed by aviad.in...@gmail.com - Refactored the core of the yielder functionality out, to allow the tree-api implementation with less boiler-plate. Refactored the core of the yielder functionality out, to allow the tree-api implementation with less boiler-plate. Apr 03, 2009 r88 ([No log message]) committed by aviad.in...@gmail.com - [No log message] [No log message]

issue 14 (Boolean array set/get code generation not optimal) reported by aviad.in...@gmail.com - Since the opcode for set/get value to/from a boolean array is the same as it is for the byte array (BASTORE/BALOAD), and since the boolean array is saved as a java.lang.Object slot, and since there is no real way to tell which array it is from the Opcode. So the origin code of: // method vars: boolean[] arr = ...; int idx = ...; // code: stack <- arr[idx]; Results in code that does essentially this: // vars are promoted to member slots: Object arr = this.slot$1; int idx = this.slot$2; boolean c; // need to know the type of array: if (arr.getClass().getComponentType().equals(Byte.TYPE)) { stack <- java.lang.reflect.Array.getByte(arr, idx); else { stack <- java.lang.reflect.Array.getBoolean(arr, idx); } This could be improved by looking-ahead and checking is the type of the assigned variable, and then create the correct CHECKCAST bytecode (to [Z or [B), or by keeping metadata on the slots so that we could tell what was their original type, even after merger with other types, to better deduce bytecode creation.

Since the opcode for set/get value to/from a boolean array is the same as it is for the byte array (BASTORE/BALOAD), and since the boolean array is saved as a java.lang.Object slot, and since there is no real way to tell which array it is from the Opcode. So the origin code of: // method vars: boolean[] arr = ...; int idx = ...; // code: stack <- arr[idx]; Results in code that does essentially this: // vars are promoted to member slots: Object arr = this.slot$1; int idx = this.slot$2; boolean c; // need to know the type of array: if (arr.getClass().getComponentType().equals(Byte.TYPE)) { stack <- java.lang.reflect.Array.getByte(arr, idx); else { stack <- java.lang.reflect.Array.getBoolean(arr, idx); } This could be improved by looking-ahead and checking is the type of the assigned variable, and then create the correct CHECKCAST bytecode (to [Z or [B), or by keeping metadata on the slots so that we could tell what was their original type, even after merger with other types, to better deduce bytecode creation.

Older