Re: JIT pluggability

[Niranjan Suri]

Hi All,

I wanted to point out some existing work in this area - OpenJIT 2 - being
developed at the Tokyo Institute of Technology by Fuyuhiko Maruyama. Here is
a link to his research page:
http://matsu-www.is.titech.ac.jp/~maruyama/research.html

Fuyuhiko's research is primarily focused on developing VM-independent JIT
compilers. To this end, he is experimenting with several VMs including the
Aroma VM (a research VM primarily developed by me).

So far, I have been a passive observer on the Classpath list. However, I
would be interested in contributing to an effort to define such a standard
interface. If there is a spinoff group, please let me know.

Thanks!

Sincerely,
Niranjan
----------------------------------------------------------------------
Niranjan Suri                                            address@hidden
Institute for Human & Machine Cognition              40 S. Alcaniz St.
University of West Florida                         Pensacola, FL 32502


----- Original Message -----
From: "Tom Tromey" <address@hidden>
To: "GNU Classpath Project" <address@hidden>
Sent: Thursday, January 08, 2004 6:48 PM
Subject: JIT pluggability


> A few of us (at least Dalibor, Grzegorz, Mark, and me) have talked a
> bit on irc about other possibilities for collaboration in the free
> Java.  Classpath has been such a success that it seems logical that we
> should start looking for ways to expand our sphere of collaboration.
>
> One thing we talked about is the possibility of defining a standard
> pluggable JIT interface, making it easier to mix-and-match JITs and
> interpreters across VMs.
>
> To that end I wrote up a short bullet list of problem areas, mostly
> technical things that the VM would need to somehow export to a
> pluggable JIT.
>
> Tom
>
>
> License.
>   Does it even make sense to have a license for an API?
>   What licenses are appropriate for a JIT plugin?
>
> Language choice for API.
>   The obvious choices being:
>   C     lowest common denominator
>   C++   next-to-lowest common denominator :-)  provides some
>         abstraction benefit, maybe
>   Java  using our own tools...
>
> ABI Issues
>
> - Object layout, including array layout, field offsets, etc
> - Method call ABI
> - vtable layout
> - Interface calls.  Some systems have constant-time interface calls.
>   I suggest we require a simple name lookup, and also provide an
>   interface to constant-time calls for JITs that can take advantage of
>   them.
> - Exception handling - throwing and catching.
> - Name lookup, eg class, method, etc.
> - Garbage collector interface.
> - Synchronization API
> - API for "new"
> - Cast checking API
> - Array assignment API
> - Class initialization API
>
>
> General API
>
> - Verifier interface?
>   Does the verifier do all checking or does it impose some
>   requirements on the JIT/interpreter?  (Some verifiers choose to
>   delay some checking until interpretation.)
>   Does the JIT want/need information already computed by the verifier?
>   For instance basic blocks or the type map at a given statement.
>
> - Some kind of negotiation API.  The JVM can indicate its
>   requirements, the JIT can indicate its capabilities.  Non-matching
>   JITs will be ignored by the JVM.
>
>   For instance, gcj is pretty much tied to a conservative GC; if
>   there were a JIT that couldn't work in this environment it wouldn't
>   make sense to try to load it into libgcj.
>
>
> Lower Priority
>
> - Debugging interface
> - Optimization interface?
>     Keeping track of quality of compiler?
>     Bookkeeping for profiling?
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath
>