Webrev for throwing some exceptions from HSAIL

[Doug Simon]

On Dec 10, 2013, at 5:03 PM, Eric Caspole <eric.caspole at amd.com> wrote:

> Hi Doug,
> I am cross-posting this to sumatra-dev since exceptions might be interesting to that audience, I should have done it at first.
> 
> On 12/10/2013 07:03 AM, Doug Simon wrote:
>> Hi Eric,
>> 
>> Apart from the Eclipse errors and warnings (see below), the Java code looks ok.
> 
> How do you get those errors and warnings shown below? I ran
> 
> "mx eclipseformat -e /opt/eclipse4.3.1/“

This is (unfortunately) not the same as compiling with Eclipse. The only way to be sure is to open up the code in Eclipse and look at the Problems view.

> which I thought was right

It’s half right ;-)

> , and I just see 2 little comment reformatting things. Normally I use NetBeans 7.4, it already supports JDK 8, from your own company :)

For better or worse, the Graal team is heavily invested in Eclipse in terms of experience and expectations.

> Either way I will fix those things.

No problem, I’m always willing to fix them up when integrating your patches. I just want to make you aware of why you may see such changes.

> gpu_hsail.cpp:
>> 
>>   inline void init() {
>> 
>> Why a separate init() function for HSAILKernelException? Seems like an inline constructor would do the same thing.
>> 
> 
> Yes I agree, that would be better.
> 
>>       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).
> 
> Yes that is true. We are still investigating how to do the debug info for HSAIL code and will get more into that in the next weeks. Then we will be able to have better unwind features and so on.
> 
>> 
>> 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?
> 
> That is a typo, I will fix it.
> Thanks for your comments,

-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
>>> 
>> 
>> 
>