ClassModel.parse Exception when calling abstract method to aparapi

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create class with abstract run method
2. Call an implementation of this class from a kernel
3. Recieve exception

What is the expected output? What do you see instead?
I would expect aparapi to execute the passed method.
Instead I get a NullPointerException in Classmodel.parse() and aparapi reverts 
to JTP.

What version of the product are you using? On what operating system?
x86_64 r#997 
Windows 7 Professional 64bit
JRE 1.7.0 64bit

Please provide any additional information below.
I'm not entirely sure if I'm still in the usecase of aparapi, but I don't 
really see where the problem could be. I'm pretty much just wrapping a class 
around otherwise executable code. 
Is this level of indirection unsupported?
Is there a way of debugging the aparapi.jar without building it myself?

Errorstack below:
Apr 08, 2013 3:46:28 PM com.amd.aparapi.KernelRunner warnFallBackAndExecute
WARNING: Reverting to Java Thread Pool (JTP) for class myClass$1: 
java.lang.NullPointerException
com.amd.aparapi.AparapiException: java.lang.NullPointerException
    at com.amd.aparapi.Entrypoint.getOrUpdateAllClassAccesses(Entrypoint.java:275)
    at com.amd.aparapi.Entrypoint.resolveCalledMethod(Entrypoint.java:439)
    at com.amd.aparapi.Entrypoint.<init>(Entrypoint.java:481)
    at com.amd.aparapi.ClassModel.getEntrypoint(ClassModel.java:2635)
    at com.amd.aparapi.ClassModel.getEntrypoint(ClassModel.java:2643)
    at com.amd.aparapi.KernelRunner.execute(KernelRunner.java:1380)
    at com.amd.aparapi.Kernel.execute(Kernel.java:1774)
    at com.amd.aparapi.Kernel.execute(Kernel.java:1705)
    at com.amd.aparapi.Kernel.execute(Kernel.java:1690)
    at MyClass.main(Console.java:11)
Caused by: java.lang.NullPointerException
    at com.amd.aparapi.ClassModel.parse(ClassModel.java:2452)
    at com.amd.aparapi.ClassModel.parse(ClassModel.java:2437)
    at com.amd.aparapi.ClassModel.<init>(ClassModel.java:138)
    at com.amd.aparapi.Entrypoint.getOrUpdateAllClassAccesses(Entrypoint.java:246)
    ... 11 more

Original issue reported on code.google.com by Johannes...@googlemail.com on 8 Apr 2013 at 2:13

[GoogleCodeExporter]

I am trying to work out what your code hierarchy looks like

Is it

class MyKernel extends Kernel{
   void myAlgorithm(){
   }
   void run(){
      myAlgorithm();
   }
}

or 
class MyAlgorithm{
   void myAlgorithm(){
   }
}
class MyKernel extends Kernel{

   void run(){
      MyAlgorithm.myAlgorithm();
   }
}

or possibly 

class MyKernel extends Kernel{
   class MyAlgorithm{
       void myAlgorithm(){
       }
   }
   void run(){
      MyAlgorithm.myAlgorithm();
   }
}

Only the first one is supported...  In the new lambda branch we are somewhat 
forced to provide support for the second form, but Aparapi dissallows any call 
outside of the base or derived class hierarchy. Even if the class is an inner 
class (which is really just another class when you get under the syntactic 
sugar).

Can you outline (no need to show actual code ;) ) what form you are trying. 

WRT debugging.  We leave the debug symbols in the jar file for Aparapi, so you 
can just pull the SVN tree add aparapi.jar to your classpath and link aparapi 
to the source root to single step in GDB/Eclipse/IntelliJ.  You don't have to 
build yourself to debug. 

Gary 

Original comment by frost.g...@gmail.com on 8 Apr 2013 at 3:10

[GoogleCodeExporter]

My hierarchy looks approximately like this:

class MyAlgorithm{
   void myAlgorithm(){
   }
}
class MyClass{
  class MyKernel extends Kernel{

     void run(){
        MyAlgorithm.myAlgorithm();
     }
  }
}

Therefor I suppose it isn't supported.
Do you plan to support it in the future, or is the dependency management to 
complicated?
Thanks for your fast response.

Johannes

Original comment by Johannes...@googlemail.com on 9 Apr 2013 at 8:42

[GoogleCodeExporter]

Johannes

So we are relaxing some constraints. Specifically

Static methods of MyAlgorithm which do not change static state should be 
supportable.

Even instance (non static) methods through a common instance, which do not 
change state of MyAlgorithm should be supportable.

We have to prove that the above methods do not cause 'store race' conditions 
before allowing them to execute on the GPU.  

The lambda branch (kind of usable now, but not recommended ;) ) has removed 
some of these restrictions. Actually we had to do this because Lambda functions 
do not share a base class - like Kernel - to provide helper functions like 
cos(), sin(), atomicInc() etc.

If you want to have each 'thread' on the GPU access it's own instance of 
MyAlgorithm, then we will be able to support this (we already do for simple 
getters and setters, but will extend this for lambda time). 

Sorry this is unstructured, this code is still developing

Gary

Original comment by frost.g...@gmail.com on 9 Apr 2013 at 1:28