From eric.caspole at amd.com Tue Dec 10 08:03:37 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 10 Dec 2013 11:03:37 -0500 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Message-ID: <52A73B59.5080904@amd.com> 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/" which I thought was 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 :) Either way I will fix those things. > > 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, Eric > > -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 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/ >> >> 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 >> > > From doug.simon at oracle.com Tue Dec 10 08:22:16 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 Dec 2013 17:22:16 +0100 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: <52A73B59.5080904@amd.com> References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> <52A73B59.5080904@amd.com> Message-ID: On Dec 10, 2013, at 5:03 PM, Eric Caspole 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 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/ >>> >>> 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 >>> >> >> > From tom.deneau at amd.com Tue Dec 10 08:41:13 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 10 Dec 2013 16:41:13 +0000 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Message-ID: Gilles -- Some comments below -- Tom > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev- > bounces at openjdk.java.net] On Behalf Of Gilles Duboscq > Sent: Tuesday, December 10, 2013 9:05 AM > To: Doug Simon > Cc: Caspole, Eric; graal-dev at openjdk.java.net > Subject: Re: Webrev for throwing some exceptions from HSAIL > > 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. > Yes, this was indeed a baby step. We realized with graal's policy of providing the framestate back at the last side-effecting bytecode means we don't get even get the exact bci on deoptimizations. Our plan for the next phase is to provide enough information and actually build up the correct interpreter frames back and restart execution in the interpreter back on the host side. > 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! > Is this true even when the DeoptimizationReason is something explicit like BoundsCheckException? (realizing that all the problems with exact bci mentioned above still hold) > 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. > I'm not really sure what affect OptimisticOptimizations.NONE or ALL had on any of this. With both NONE and ALL, we definitely still got both DeoptNodes and UnwindNodes. (The UnwindNodes came from profiling information I think). We switched to ALL in the latest just to make it more similar to what the AMD64 backend was doing. > -Gilles > > > > On Tue, Dec 10, 2013 at 1:03 PM, Doug Simon > 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/hsai > l/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/hsai > l/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/hsai > l/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/hsai > l/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/hsai > l/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/hsai > l/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/hsai > l/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/hsai > l/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/hsai > l/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/hsai > l/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/hsai > l/test > > line 67 Checkstyle Problem > > > > > > > > On Dec 10, 2013, at 1:31 AM, Caspole, Eric > 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 > > > > > > > From duboscq at ssw.jku.at Tue Dec 10 09:31:30 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 10 Dec 2013 18:31:30 +0100 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Message-ID: On Tue, Dec 10, 2013 at 5:41 PM, Tom Deneau wrote: > Gilles -- > > Some comments below > > -- Tom > > > -----Original Message----- > > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev- > > bounces at openjdk.java.net] On Behalf Of Gilles Duboscq > > Sent: Tuesday, December 10, 2013 9:05 AM > > To: Doug Simon > > Cc: Caspole, Eric; graal-dev at openjdk.java.net > > Subject: Re: Webrev for throwing some exceptions from HSAIL > > > > 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. > > > > Yes, this was indeed a baby step. > > We realized with graal's policy of providing the framestate back at the > last > side-effecting bytecode means we don't get even get the exact bci on > deoptimizations. > > Our plan for the next phase is to provide enough information and > actually build up the correct interpreter frames back and restart > execution in the interpreter back on the host side. > OK, but i wonder what are the semantics there since the data has already been partially modified by the other kernel workitems which didn't deoptimize. In general when we think about parallelization we consider that it's only safe to parallelize sections where there is no deoptimization since this means we are guaranteed not to deopt to a state of the data that is invalid for the interpreter. I suppose in the case of streams you are relying on the relaxed semantics of parallel streams. How are you going to ensure that all element are processed in the case of deoptimization? > > > > 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! > > > > Is this true even when the DeoptimizationReason is something explicit like > BoundsCheckException? > (realizing that all the problems with exact bci mentioned above still hold) > Yes, the compiler does not apply the exception semantics to the deoptimizations. We use deoptimization for exceptions (amongst other things) because it make optimization easier since we don't need to respect exception semantics for deoptimization and we just let the interpreter figure out if and where the exception should be thrown. > > > 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. > > > > I'm not really sure what affect OptimisticOptimizations.NONE or ALL had on > any of this. > With both NONE and ALL, we definitely still got both DeoptNodes and > UnwindNodes. (The > UnwindNodes came from profiling information I think). > We switched to ALL in the latest just to make it more similar to what the > AMD64 backend > was doing. > If you really implement deoptimization then ALL is the way to go. But i thought you would prefer unwind nodes which tell you that an exception actually needs to be thrown. The fact that you still got a mixture of deopt and unwind nodes probably means that there was a problem around inlining where the root method and the inlinined methods didn't use the same policy. > > > -Gilles > > > > > > > > On Tue, Dec 10, 2013 at 1:03 PM, Doug Simon > > 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/hsai > > l/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/hsai > > l/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/hsai > > l/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/hsai > > l/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/hsai > > l/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/hsai > > l/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/hsai > > l/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/hsai > > l/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/hsai > > l/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/hsai > > l/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/hsai > > l/test > > > line 67 Checkstyle Problem > > > > > > > > > > > > On Dec 10, 2013, at 1:31 AM, Caspole, Eric > > 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 > > > > > > > > > > > > From christian.thalinger at oracle.com Tue Dec 10 11:27:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Dec 2013 11:27:52 -0800 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Message-ID: <5B02E26C-8CC1-4F57-919B-073295734001@oracle.com> On Dec 10, 2013, at 9:31 AM, Gilles Duboscq wrote: > On Tue, Dec 10, 2013 at 5:41 PM, Tom Deneau wrote: > >> Gilles -- >> >> Some comments below >> >> -- Tom >> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev- >>> bounces at openjdk.java.net] On Behalf Of Gilles Duboscq >>> Sent: Tuesday, December 10, 2013 9:05 AM >>> To: Doug Simon >>> Cc: Caspole, Eric; graal-dev at openjdk.java.net >>> Subject: Re: Webrev for throwing some exceptions from HSAIL >>> >>> 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. >>> >> >> Yes, this was indeed a baby step. >> >> We realized with graal's policy of providing the framestate back at the >> last >> side-effecting bytecode means we don't get even get the exact bci on >> deoptimizations. >> >> Our plan for the next phase is to provide enough information and >> actually build up the correct interpreter frames back and restart >> execution in the interpreter back on the host side. >> > > OK, but i wonder what are the semantics there since the data has already > been partially modified by the other kernel workitems which didn't > deoptimize. > In general when we think about parallelization we consider that it's only > safe to parallelize sections where there is no deoptimization since this > means we are guaranteed not to deopt to a state of the data that is invalid > for the interpreter. > I suppose in the case of streams you are relying on the relaxed semantics > of parallel streams. > How are you going to ensure that all element are processed in the case of > deoptimization? Correct. This is something we have talked about already in the Sumatra scope. Before we can throw exceptions in GPUs we have to have some kind of work item logic. I think trying to throw exceptions without having properly set up work items and a way to undo or record which items have already been processed is premature and not something we want. We need to resume talking about work items and start to implement it. > > >> >> >>> 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! >>> >> >> Is this true even when the DeoptimizationReason is something explicit like >> BoundsCheckException? >> (realizing that all the problems with exact bci mentioned above still hold) >> > > Yes, the compiler does not apply the exception semantics to the > deoptimizations. We use deoptimization for exceptions (amongst other > things) because it make optimization easier since we don't need to respect > exception semantics for deoptimization and we just let the interpreter > figure out if and where the exception should be thrown. > > >> >>> 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. >>> >> >> I'm not really sure what affect OptimisticOptimizations.NONE or ALL had on >> any of this. >> With both NONE and ALL, we definitely still got both DeoptNodes and >> UnwindNodes. (The >> UnwindNodes came from profiling information I think). >> We switched to ALL in the latest just to make it more similar to what the >> AMD64 backend >> was doing. >> > > If you really implement deoptimization then ALL is the way to go. > But i thought you would prefer unwind nodes which tell you that an > exception actually needs to be thrown. > The fact that you still got a mixture of deopt and unwind nodes probably > means that there was a problem around inlining where the root method and > the inlinined methods didn't use the same policy. > > >> >>> -Gilles >>> >>> >>> >>> On Tue, Dec 10, 2013 at 1:03 PM, Doug Simon >>> 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/hsai >>> l/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/hsai >>> l/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/hsai >>> l/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/hsai >>> l/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/hsai >>> l/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/hsai >>> l/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/hsai >>> l/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/hsai >>> l/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/hsai >>> l/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/hsai >>> l/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/hsai >>> l/test >>>> line 67 Checkstyle Problem >>>> >>>> >>>> >>>> On Dec 10, 2013, at 1:31 AM, Caspole, Eric >>> 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 From eric.caspole at amd.com Wed Dec 18 06:56:46 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Wed, 18 Dec 2013 09:56:46 -0500 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: <5B02E26C-8CC1-4F57-919B-073295734001@oracle.com> References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> <5B02E26C-8CC1-4F57-919B-073295734001@oracle.com> Message-ID: <52B1B7AE.4030806@amd.com> As Chris mentioned, let's try to come up with a workitem model that relates to the deoptimizations, etc. GPU devices process elements in wavefronts or warps which are often size 32 or 64 workitems at once. Devices can usually execute several wavefronts simultaneously. All the workitems in each wavefront are processed in lock-step unless there is divergence, in which case each side of a branch will be predicated off in turn until the branches reunite. So at any given time, there can be some wavefronts that already definitely completed, some that have not started yet, and some that are in flight. Since the total job size being offloaded could be enormous, I think we should keep track of the workitems/wavefronts currently in flight at any given moment if we need to deoptimize or safepoint etc. This will normally be hundreds or thousands of workitems at once for current hardware. We know the current workitem id in the job for any given GPU core, and we know how many total GPU cores are on a device, so with that we can work out what is the state of partially completed work if there is a deopt etc. We can prevent future wavefronts from starting by explicit checks, and workitems that already completed, at least in the case of HSA for the use cases we have working, their results are already stored back in the heap so that should not require any more attention. I am starting to experiment with this on our hardware. Will this idea work on PTX? It seems like it will work for HSA. Let me know your ideas. Thanks, Eric On 12/10/2013 02:27 PM, Christian Thalinger wrote: > > On Dec 10, 2013, at 9:31 AM, Gilles Duboscq wrote: > >> On Tue, Dec 10, 2013 at 5:41 PM, Tom Deneau wrote: >> >>> Gilles -- >>> >>> Some comments below >>> >>> -- Tom >>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev- >>>> bounces at openjdk.java.net] On Behalf Of Gilles Duboscq >>>> Sent: Tuesday, December 10, 2013 9:05 AM >>>> To: Doug Simon >>>> Cc: Caspole, Eric; graal-dev at openjdk.java.net >>>> Subject: Re: Webrev for throwing some exceptions from HSAIL >>>> >>>> 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. >>>> >>> >>> Yes, this was indeed a baby step. >>> >>> We realized with graal's policy of providing the framestate back at the >>> last >>> side-effecting bytecode means we don't get even get the exact bci on >>> deoptimizations. >>> >>> Our plan for the next phase is to provide enough information and >>> actually build up the correct interpreter frames back and restart >>> execution in the interpreter back on the host side. >>> >> >> OK, but i wonder what are the semantics there since the data has already >> been partially modified by the other kernel workitems which didn't >> deoptimize. >> In general when we think about parallelization we consider that it's only >> safe to parallelize sections where there is no deoptimization since this >> means we are guaranteed not to deopt to a state of the data that is invalid >> for the interpreter. >> I suppose in the case of streams you are relying on the relaxed semantics >> of parallel streams. >> How are you going to ensure that all element are processed in the case of >> deoptimization? > > Correct. This is something we have talked about already in the Sumatra scope. Before we can throw exceptions in GPUs we have to have some kind of work item logic. I think trying to throw exceptions without having properly set up work items and a way to undo or record which items have already been processed is premature and not something we want. > > We need to resume talking about work items and start to implement it. > >> >>