[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
JIT pluggability
From: |
Tom Tromey |
Subject: |
JIT pluggability |
Date: |
08 Jan 2004 17:48:59 -0700 |
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?
- JIT pluggability,
Tom Tromey <=