Saalma / aparapi

Automatically exported from code.google.com/p/aparapi
Other
0 stars 0 forks source link

anonymous inner class kernel cannot access data members of enclosing class #78

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create an anonymous inner class kernel
2. kernel accesses data members of the enclosing class
3. You will get the fallback to JTP as shown below

What is the expected output? What do you see instead?

It would be nice if this works, other wise it makes anonymous inner class 
kernel a little less useful.

Nov 01, 2012 5:00:05 PM com.amd.aparapi.KernelRunner warnFallBackAndExecute
WARNING: Reverting to Java Thread Pool (JTP) for class 
com.amd.aparapi.test.runtime.IssueXX$1: Using java objects inside kernels is 
not supported
com.amd.aparapi.ClassParseException: Using java objects inside kernels is not 
supported
    at com.amd.aparapi.Entrypoint.getFieldFromClassHierarchy(Entrypoint.java:190)
    at com.amd.aparapi.Entrypoint.<init>(Entrypoint.java:696)
    at com.amd.aparapi.ClassModel.getEntrypoint(ClassModel.java:2639)
    at com.amd.aparapi.ClassModel.getEntrypoint(ClassModel.java:2647)
    at com.amd.aparapi.KernelRunner.execute(KernelRunner.java:1371)
    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 com.amd.aparapi.test.runtime.IssueXX.test(IssueXX.java:34)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
    at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
    at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
    at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906)

Please use labels and text to provide additional information.

Original issue reported on code.google.com by ecasp...@gmail.com on 1 Nov 2012 at 9:04

GoogleCodeExporter commented 8 years ago

Original comment by ecasp...@gmail.com on 1 Nov 2012 at 9:07

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by ecasp...@gmail.com on 1 Nov 2012 at 9:48

GoogleCodeExporter commented 8 years ago
Eric I think you should simplify the test case. It has artifacts of three 
seperate use cases. 

If I understand correctly the issue is that the static fields (values and 
results) of the containing class cannot be accessed from the anonymous 
innerclass (because of the synthetic obeject reference in the bytecode). 

I think you test case should be:-

package com.amd.aparapi.test.runtime;

import static org.junit.Assert.assertTrue;
import org.junit.Test;
import com.amd.aparapi.Kernel;

public class Issue78 {

   static final int size = 256;
   final int[] values = new int[size];
   final int[] results = new int[size];

   @Test public void test() {
      Kernel kernel = new Kernel() {
         @Override public void run() {
            int gid = getGlobalId();
            results[gid] = values[gid];
         }   
      };  
      kernel.execute(size);
      assertTrue("ran on GPU", kernel.getExecutionMode()==Kernel.EXECUTION_MODE.GPU);
   }
}

Original comment by frost.g...@gmail.com on 2 Nov 2012 at 6:51

GoogleCodeExporter commented 8 years ago
I removed the unnecessary fooBar method but left the initialization and final 
comparison assert so it will still be a useful test when this functionalty is 
getting implemented.

Now that I look at it, your version is more suitable as a codegen test, right? 
Because it will fail in the bytecode processing.

Original comment by ecasp...@gmail.com on 9 Nov 2012 at 5:24

Attachments: