Currently the JVM backend has not been completed yet, and cannot translate
all valid RPython programs; however, most conceptual hurdles have been
overcome, and what remains is the implementation of all corner cases.  
After that, another important piece of remaining work will be to
generate more optimized bytecode for better performance.

\subsubsection{JVM in a Nutshell}

The JVM is a  virtual machine tailored closely to the Java programming
language \cite{JLS}.  All code in the JVM is encapsulated within a
class.  Each class must inherit from another class, and the resulting
inheritance tree is rooted in \lstinline!java.lang.Object!.  Each class may
also implement any number of interfaces, which entails an obligation
to implement certain methods.  Each class has some set of fields, and
a disjoint set of methods.  
Method invocations are annotated by a signature, containing the
name of the method, and the static types of its arguments and of its
return value; the signature is needed to verify the bytecode 
and to correctly resolve method invocations.
For further details, the reader is referred to  \cite{JvmSpec}.


\subsubsection{Unsigned values}

The JVM's lack of support for unsigned operations also causes a problem; currently, unsigned int and long values are stored as instances of their signed counterparts.  Most operations, such as addition and bitwise manipulation, work equally well on signed and unsigned values, but we must use special subroutines to perform comparison between unsigned values.

\subsubsection{Generic typing and boxed values}
\label{sect:jvm-generics}

Although the Java language introduced support for generic types in
version 1.5 \cite{286957}, this support is only skin-deep: generic
types are "erased" and replaced by casts when the class is compiled
down to JVM bytecodes.  The JVM itself ignores generic types.  

Because RPython's type system allows for generic containers, including generic containers of scalar values such as integers, the JVM backend must introduce casts each time that an object is withdrawn from a container.  We also box and unbox scalars appropriately.  Although it is known statically that these casts will succeed, they are required for the JVM's bytecode verifier to accept the classes we generate.

\subsubsection{First-order functions and classes}

Unlike Java, RPython allows programmers to pass around functions
as first-order objects.  In order to implement this in the JVM, it is necessary 
to wrap each of these functions in its own class.  Taking the address of
the function can then be implemented by instantiating this class.

The JVM backend collects the type signatures of all functions whose addresses
are taken at some point in the RPython program.  For each unique type
signature, an abstract base class is created that contains one method, 
\lstinline"invoke", with parameter and return types dictated by
the signature.  In this way, a pointer to any function with a given signature can
be represented by a pointer to the appropriate base class.

When compiling a stand-alone function with signature \lstinline"S", a class is created 
which wraps the function and which extends the abstract base class 
corresponding to \lstinline"S".  This class can then be instantiated as needed to create
pointers to this function.

RPython also supports class objects as first-order values.  While the JVM does not support this directly, it does support reflection, which has the same capabilities.  Pointers to RPython classes are therefore translated into instances of \lstinline"java.lang.Class", which can be used to create new instances of a class without specifying the class name statically.

\begin{figure}[t]
   \epsfig{file=jvm-exception-hierarchy, scale=.5} % requires the graphicx package
   \caption{Naive type hierarchy}
   \label{fig:jvm-exception-hierarchy}
\end{figure}

\begin{figure}[t]
   \epsfig{file=jvm-exception-hierarchy-fixed, scale=.5} % requires the graphicx package
   \caption{Actual hierarchy generated by GenJVM}
   \label{fig:jvm-exception-hierarchy}
\end{figure}

\subsubsection{Exceptions}

In Java, all classes are descended from a class \lstinline"java.lang.Object";\footnote{To distinguish between Java's \lstinline!java.lang.Object! and RPython's \lstinline{Object} class, we always use the fully-qualified \lstinline{java.lang.Object} to refer to the Java class} one particular sub-class, \lstinline"java.lang.Throwable", is special, because it is the ancestor of all exceptions.  Attempts to throw any object as an exception whose class does not descend from \lstinline"java.lang.Throwable" are rejected by the verifier.  RPython has a similar class structure.  Like Java, it has a class, \lstinline"Object", at the root of the type hierarchy, and a distringuished sub-class thereof, \lstinline"exceptions.Exception", from which all exceptions are derived.  While this parallel structure is necessary to allow RPython exceptions to be thrown by the JVM, it is not sufficient by itself, and one further trick is necessary.

The problem is that each RPython class, including \lstinline"Object", is translated into a new Java class.  The translated versions of each RPython class, therefore, form a sub-tree within the Java class hierarchy.  If this translation were not carefully handled, the result would be that RPython exceptions could not be thrown using the JVM's exception handling mechanisms, because all RPython classes, including exceptions, would be a sibling of the \lstinline"java.lang.Throwable" sub-tree, as depicted in Figure \ref{fig:jvm-exception-hierarchy}.  

To avoid this problem, the JVM backend treats the RPython class \lstinline"Object" specially.  Unlike other RPython classes, \lstinline"Object" is actually translated into a Java \emph{interface}, which has two implementations.  The first implementation descends from \lstinline"java.lang.Object", and is used as the superclass for all RPython classes \emph{except} for \lstinline"exceptions.Exception".  The second implementation descends from \lstinline"java.lang.Throwable", and is used as the super-class for \lstinline"exceptions.Exception".  This effectively splits the RPython hierarchy into two sub-trees, as depicted in Figure \ref{jvm-exception-hierarchy-fixed}.  The fact that both implementations of \lstinline"Object" implement the same interface means that pointers which may point to any RPython object can use the interface as their static type and retain type safety.