Substitution/Replacements problem

Christian Thalinger christian.thalinger at oracle.com
Mon Mar 3 16:47:21 PST 2014


On Mar 3, 2014, at 3:25 PM, Eric Caspole <eric.caspole at amd.com> wrote:

> Hi everybody,
> We have a lot of lambda based tests that are not in the public repo yet, waiting for JDK 8 to come to Graal. In these tests, I found a problem with the way replacements are being done now.
> 
> See this method:
> 
> graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java
> 
> 
> 107     @Override
> 108     public StructuredGraph getMethodSubstitution(ResolvedJavaMethod original) {
> 109         for (GraphProducer gp : graphProducers) {
> 110             StructuredGraph graph = gp.getGraphFor(original);
> 111             if (graph != null) {
> 112                 return graph;
> 113             }
> 114         }
> 115         return super.getMethodSubstitution(original);
> 116     }
> 
> 
> Here it loops over the backends until it gets a hit. In our tests, I found that while we are compiling an HSAIL kernel that is actually a Stream API lambda, when it goes into getIntrinsicGraph(), it will go into getMethodSubstitution() and look for substitutions in the PTX backend, see the "lambda$" method we are compiling and try to produce a PTX kernel of the thing we are in the middle of compiling for HSAIL, which was a shock :)
> 
> Up til now, we have been using the replacements/inline mechanism for example AtomicInteger that end up as fence/load/fence type ops, and other uses, that get inlined into the kernel body and that is working well so far.
> 
> I have a suitable PTX card in my box so I might be the only one in the group that might see this problem. The existing HSAIL KernelTester tests in the public repo do not get this problem since the harness sends an ordinary method to get HSAIL-compiled and they are not called "lambda$..."
> 
> I think I see that the strategy for offloading for PTX so far is doing a "replacement" of a CPU method with a GPU kernel. But we also want to have some replacements/inlining inside the kernel.

Hmm, interesting problem.  Although I don’t have an answer to your question I want to put out this general question:

How are we going to decide which methods to offload to which GPU given that there is more than one GPU in the system?

> 
> What is the best way to fix this problem?
> Thanks,
> Eric
> 
> 



More information about the graal-dev mailing list