sofent / infomancers-collections Goto Github PK

What steps will reproduce the problem?
1. Run test case "booleanArray()"

What is the expected output? What do you see instead?
I'd expect the test to run properly, but it doesn't.

The reason is _probably_ this: The bytecode used to load boolean values from a 
boolean array is 
BALOAD, which is the same for loading bytes from a byte array. When the yielder 
manipulator 
encounters BALOAD, it changes it to a bytecode set which basically does 
"Array.getByte(arr, 
index)". However, that doesn't work for a boolean array as the argument is 
wrong. 


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. The runtime compiler emits a LOAD, LOAD, PUTFIELD set after each STORE

What is the expected output? What do you see instead?
I would expect the STORE opcode to be replaced entirely by only a PUTFIELD 
opcode, and an ALOAD 
opcode coming at its correct location.
This location needs to be mapped by a statistical gatherer, much like the State 
counter is doing now 
for the state switch.

What steps will reproduce the problem?
1. Create a subclassing tree such as Yielder->SomeSubclass->YielderImplementor
2. Leave the yieldNextCore as abstract in SomeSubclass
3. Implement yieldNextCore in YeilderImplementor.

What is the expected output? What do you see instead?
I would expect everything to work normally, but the transformation doesn't
identify YielderImplementor as a subclass of Yielder.

What steps will reproduce the problem?
1. Compile the Yielder code without debug information.
2. Run the unit tests.
3. NoSuchElementException occurs.

What is the expected output? What do you see instead?
java.util.NoSuchElementException
at java.util.LinkedList.remove(LinkedList.java:788)
java.util.LinkedList.removeLast(LinkedList.java:144)
at
com....asm.LocalVariableMapper$MyMethodAdapter.visitVarInsn(LocalVariableMapper.
java:98)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at com...asm.YielderTransformer.transform(YielderTransformer.java:80)
at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
...

What version of the product are you using? On what operating system?
Latest SVN, Java 6, Linux.

Please provide any additional information below.

What steps will reproduce the problem?
1. Compile the source using eclipse
2. Run the junit tests
3.

What is the expected output? What do you see instead?
Any tests using the foreach style for loop will fail

What version of the product are you using? On what operating system?
Latest SVN, Eclipse 3.3, Java 6, Linux

Please provide any additional information below.

/**
 * [compiled with]
 *   d:\dev\jdk\bin\javac -d ..\bin -cp
D:\dev\asm-3.1\lib\asm-3.1.jar;D:\dev\jyield\yielder-0.2.2.jar
com\bestsoft\testjyield\Foo.java
 * [run with]
 *   d:\dev\jdk\bin\java -javaagent:d:\dev\jyield\yielder-0.2.2.jar -cp
.;d:\dev\jyield\yielder-0.2.2.jar;d:\dev\asm-3.1\lib\asm-3.1.jar
com.bestsoft.testjyield.Foo
 * [expect output]
 *   range:0
 *   main:0
 *   range:1
 *   main:1
 *   ....
 * [actually output]
 *   range:0
 *   range:1
 *   ...
 *   range:9
 *   main:9
 *   range:0
 *   range:1
 *   ...
 *   range:9
 *   main:9
 *   ...
 */

package com.bestsoft.testjyield;
import com.infomancers.collections.yield.Yielder;

public class Foo {
    public static Iterable<Integer> range(int begin, int end) {
        final int a = begin;
        final int b = end;
        return new Yielder<Integer>() {
            public void yieldNextCore() {
                for (int i = a; i < b; ++i) {
                    System.out.println("range:" + i);
                    yieldReturn(new Integer(i));
                }
            }
        };
    }

    public static void main(String[] args) {
        Iterable<Integer> iter = range(1, 10);
        for (Integer i: iter) {
            System.out.println("main:" + i);
        }
    }
}

What steps will reproduce the problem?
1. Create a nested loop, possibly over a matrix of integers.
2. Make sure to use the new for-each style.

What is the expected output? What do you see instead?
Expected: All elements in the nested loop (matrix).
Result: Sometimes it doesn't do the runtime-compilation well, sometimes there 
seems to be (this is 
a guess) an override of local variable names.

What steps will reproduce the problem?
1. Using a local variable of an integral type and using the ++ or -- operator 
on it.

What is the expected output? What do you see instead?
I expect the application to work - And to increment or decrement a class field 
which is generated to 
take the local varialbe's place.

Some useful updates to the yielder.xml build file that assists in running
the JUnit tests.

This build file requires that junit-4.1.jar be placed in the lib directory.

The yielder.xml file searches for a JDK in a place which is Mac OS X specific.

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.

What steps will reproduce the problem?
1. Create a yielder class, and in it, 
2. Create a local variable of a reference type.
3. Call a method on the local variable.

What is the expected output? What do you see instead?
The application should run normally, however the verifier throws a "method: 
yieldNextCore 
signature: ()V) Incompatible object argument for function call" exception 
message.

Hello,

the performance is suboprimal if you use yielder recursively, like in your 
example:
 for (TreePath res : new TreeModelYielder(model, curChild, bias)) {
        yield res;
      }

The problem is that for each returned value, you need to call (and return from) 
all the methods in the call stack (Yielder(t), Yielder(t.child[0]), 
Yielder(t.child[0].child[0], etc.). So the traversal of the whole tree may take 
time O(n*d), where n is number of returned nodes and d is average depth of the 
tree.

To solve this, I propose to include a method yieldMany, which takes a yielder 
and includes the child yielder results in the parent yielder's result. For 
example, instead of the aboving, you would use
yieldMany(new TreeModelYielder(model, curChild, bias)); 

I tried this, basically you need to keep stack of all Yielders, and put the top 
of to stack to "this" variable (ASTORE_0). 

I think I'll implement this for your library.

Hi, if by any chance you're still working on this project, would you consider 
adding static byte code modification in future versions?

I just downloaded the source code, created the corresponding ant task which 
delegates to TreeYielderTransformer to enhance my classes.

Coupled with maven ant-run plugin 
(http://maven.apache.org/plugins/maven-antrun-plugin/) all classes on my 
project get instrumented upon build and there is no needed for agents.

It's working great! I mainly choose static compilation due to the number of 
classes on my monolithic ear classpath (~18000) (and I was afraid to eventually 
get classloading issues).

I can send the source if you want.

Best regards.

What steps will reproduce the problem?
1. Have a class with an array as a member.
2. Create the following Yielder:
{{{
for (int i = 0; i < arr.length; i++) {
  yieldReturn(i);
}
}}}

What is the expected output? What do you see instead?
I expect it to work. Instead, there is an error from the verifier:
{{{
Exception in thread "main" java.lang.VerifyError: (class: 
com/infomancers/collections/yield/asm/YielderTests$1, method: yieldNextCore 
signature: ()V) 
Expecting to find array on stack
}}}

What steps will reproduce the problem?
1. Throw an exception
2. Catch it inside the yieldNextCore method.

What is the expected output? What do you see instead?
Application should run normally, however an error erupts.