Webrev for throwing some exceptions from HSAIL

[Gilles Duboscq]

Hi Eric,

The deoptimization mechanism and the exception mechanism are two completely
different things.
When a deoptimization happens, your only choice is to restart execution in
the interpreter.
To do so, the deoptimization points are decorated with LIRFrameState in the
backend. This LIRFrameState gives you information that allow to rebuild the
interpreter frames. For each frame you have a method, a bci, the stack and
local values and the owned monitors.

Once a deoptimization happened you can not just throw an exception because
the deoptimization informations will not tell you where the problem
actually happened, it is also not guaranteed that you have a meaningful
exception to throw corresponding to the deoptimization reason and it is not
even guaranteed that there actually was any problem at all!

I think this was the reason you were using OptimisticOptimizations.NONE
previously which should get rid of most deoptimizations and get exceptions
instead. But i suspect it was not really used everywhere which could cause
problems such as the "not compiled exception handler" deopt reason.
Maybe we should try to have a look at those things together over Skype (my
username is gilwooden) or something similar.

-Gilles



On Tue, Dec 10, 2013 at 1:03 PM, Doug Simon <doug.simon at oracle.com> wrote:

> Hi Eric,
>
> Apart from the Eclipse errors and warnings (see below), the Java code
> looks ok.
>
> gpu_hsail.cpp:
>
>   inline void init() {
>
> Why a separate init() function for HSAILKernelException? Seems like an
> inline constructor would do the same thing.
>
>       thread->set_gpu_exception_method(mh());
>
> If the exception happens in an inlined method, then mh() is the wrong
> value here (and bci will be wrong as well).
>
> gpu_hsail.hpp:
>
>   static bool execute_kernel_void_1d(address kernel, int dimX, jobject
> args, methodHandle mh, TRAPS);
>
> Why is the mh parameter no longer passed by reference?
>
> -Doug
>
> Description     Resource        Path    Location        Type
> The import com.oracle.graal.api.code is never used
>  HSAILControlFlow.java
> /com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail      line 36
> Java Problem
> The value of the field HSAILHotSpotLoweringProvider.host is not used
>  HSAILHotSpotLoweringProvider.java
> /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail
>  line 39 Java Problem
> 'abstract' modifier out of order with the JLS suggestions.
>  HSAILHotSpotLoweringProvider.java
> /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail
>  line 41 Checkstyle Problem
> The value of the local variable bci is not used
> HSAILHotSpotLIRGenerator.java
> /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail
>  line 222        Java Problem
> Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'.     ClassCastTest.java
>
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 42 Checkstyle Problem
> Line matches the illegal pattern 'System\.(out|err)\.print'.
>  ClassCastTest.java
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 73 Checkstyle Problem
> The import java.lang.reflect is never used      HSAILAssembler.java
> /com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail      line 26
> Java Problem
> The import com.oracle.graal.debug.internal is never used
>  HSAILCompilationResult.java
> /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail
>  line 37 Java Problem
> First sentence should end with a period.        ClassCastTest.java
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 14 Checkstyle Problem
> Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'.     ClassCastTest.java
>
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 27 Checkstyle Problem
> Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'.     ClassCastTest.java
>
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 27 Checkstyle Problem
> Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'.     ClassCastTest.java
>
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 42 Checkstyle Problem
> The import org.junit.Assert.assertTrue is never used    ClassCastTest.java
>
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 11 Java Problem
> Line does not match expected header line of ' \* Copyright \(c\)
> (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights
> reserved.'.    ClassCastTest.java
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 2  Checkstyle Problem
> First sentence should end with a period.        BoundsCheckTest.java
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 29 Checkstyle Problem
> The import java.util.Arrays is never used       ClassCastTest.java
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 9  Java Problem
> Line matches the illegal pattern 'System\.(out|err)\.print'.
>  BoundsCheckTest.java
>  /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test
>  line 67 Checkstyle Problem
>
>
>
> On Dec 10, 2013, at 1:31 AM, Caspole, Eric <Eric.Caspole at amd.com> wrote:
>
> > Hi everybody,
> > Tom and I came up with our first baby steps of throwing exceptions from
> HSAIL kernels back into "regular" java. This is for the context of running
> as a parallel stream such as a parallel().forEach(). This works such that
> the first kernel workitem to set an atomic after detecting a problem "wins"
> to report the exception back to java.  The kernel workitems that detect a
> problem return early even if they lose to set the flag, and the others run
> on normally. This is about the same as you get with CPU parallel streams.
> >
> > http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/<
> http://cr.openjdk.java.net/%7Eecaspole/hsail_exceptions/>
> >
> > We can now detect ArrayIndexOutOfBounds and ClassCastExceptions via
> explicit checks in the HSAIL code, and return a deoptimization reason to
> the CPU side. In the JVM kernel launch code, we check for these exceptions,
> then save the method, reason and bci in the thread, then throw using the
> THROW/CHECK mechanism from C++ back to java. When the thread later gets to
> fillInStackTrace, it uses the saved info in the thread to add the kernel
> lambda method as the top frame in the stack trace.
> >
> > Let us know what you think.
> > Thanks,
> > Eric
> >
>
>