\subsection{GPU code generation from high-level language}
GPU code generation is supported by several high-level language compilation systems. 

Lime~\cite{Dubach:2012:CHL:2254064.2254066} is a JVM compatible language which generates OpenCL code automatically.
Lime provides language extensions to Java which express coarse grain tasks and
SIMD parallelism. Its compiler generates Java bytecode, JNI glue code, and OpenCL kernels.
To enable barrier synchronization, Lime users must partition tasks at each synchronization point.

RootBeer~\cite{rootbear} compiles Java bytecode to CUDA by including a data-parallel code region in a method named
\textit{gpuMethod} declared inside a class which implements \textit{Kernel}. The 
RootBeer compiler translates the \textit{gpuMethod()} method to a CUDA kernel (details of this translation
has been discussed in Section~\ref{sec:motivation}). Similar to Lime, the programmer must partition
their kernel to enable barrier synchronization.

X10~\cite{x10-oopsla-05} and Chapel~\cite{chapel} extend their locality controls to target the GPU. Their compilers
generate CUDA code when the user explicitly specifies a task is to be scheduled on a GPU node.

Sponge~\cite{Hormati:2011:SPS:1961296.1950409} generates highly optimized CUDA code from the data flow streaming 
language StreamIt~\cite{Thies:2002:SLS:647478.727935}. Once an application is written, programmers can delegate 
non-trivial optimizations for a wide variety of GPU targets to the compiler.

Firepile~\cite{firepile} performs runtime translation of JVM bytecode from Scala programs to OpenCL kernels. It does
this by generating syntax trees from bytecode inspection at runtime, producing OpenCL kernels from traversing these
trees similar to how APARAPI performs OpenCL code generation. Firepile is also a library-oriented approach which
does not require a special-purpose compiler to perform GPU code generation.

Clyther~\cite{clyther} is similar to APARAPI, but is used from Python. It performs runtime
GPU code generation for specially annotated Clyther functions which only use a subset of the Python language
via a library-oriented approach.

% \subsubsection{Automatic GPU Code Generation}
% In OmpSs\cite{OMPSS}, the user prepares implementations for each target device while the compiler generates a 
% data dependency graph from programmer-specified \textit{data} clauses. The OmpSs runtime schedules tasks on the 
% host and devices. OpenACC\cite{OPENACC} also uses OpenMP-like directives to flag certain loops as GPU-executable, 
% while the compiler generates the necessary bridge and kernel codes.
% 
% OpenMP to GPGPU\cite{Lee:2009:OGC:1504176.1504194} transforms OpenMP into CUDA applications, and supports loop 
% transformations that optimize GPU global memory access.
% 
% PGI compiler provides {\tt acc} construct that can be used to annotate the special code region which will be 
% applied automatic CUDA code generation.

\subsection{Exception semantics in Java}

For those programming models which enable hybrid JVM and GPU execution (i.e. Lime, RootBeer, JCUDA), preserving
Java exception semantics is an important challenge which has largely been ignored up to this point.
Some previous work focused on eliminating redundant checks for null pointers and out-of-bounds accesses, enabling
optimized or native execution without breaking Java exception semantics.

RootBeer~\cite{rootbear} supports CUDA code generation for user-thrown exceptions, and in the absence of a \textit{try..catch}
block bubbles execution up the stack until one is found or the kernel exits. However, no support is provided for catching
the runtime exceptions which HJ-OpenCL focuses on.

Artigas et
al.~\cite{Artigas:2000:ALT:335231.335232} and Moreira et al.~\cite{Moreira:2000:FMJ:349214.349222} achieve MATMULT 
Java performance which is at least 80\% of the peak Fortran performance using these optimizations. 
This work generates exception-safe and -unsafe regions of code. In exception-safe regions the compiler can perform 
aggressive loop optimization such as loop tiling without breaking exception semantics.

W\"{u}rthinger et al.~\cite{Wurthinger:2007:ABC:1294325.1294343} proposes an algorithm on Static Single Assignment(SSA) form
for the JIT compiler which eliminates unnecessary bounds checking.

%ABCD~\cite{Bodik:2000:AEA:358438.349342} provides an array bounds checking elimination algorithm by adding edges to the SSA graph.
In ABCD~\cite{Bodik:2000:AEA:358438.349342}, Bodik et. al provides an array bounds checking elimination algorithm, which is based on graph traversal on an extended SSA form.

Jeffery et al.~\cite{safebounds} proposed a static annotation framework to reduce the overhead of dynamic checking in the JIT compiler. 
