JIT pluggability

[Tom Tromey]

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?