Re: JIT pluggability

[Sascha Brawer]

Tom Tromey <address@hidden> wrote on Thu, 8 Jan 2004 17:48:59 -0700:

>[standard pluggable JIT interface]

This would indeed be quite nice, IMHO.

>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...

There are some users of Classpath who cannot execute any C code, such as
Jaos and JNodeOS. If the pluggable JIT interface was in Java, these
systems would be able to use it (assuming that someone writes a JITter in
Java, like IBM did with their Jalapeño/Jikes RVM).

Also, I'd assume that the interface would be rather narrow in the sense
that it wouldn't get invoked very often in the direction VM --> JIT;
probably once for each class or method to be compiled. But the JIT would
presumably have to call a lot into the VM (for retrieving field offsets etc.).

>ABI Issues

According to IBM's publications and web pages, Jikes RVM seems to nicely
cope with different ABIs (such as the slightly different calling
conventions for AIX and MacOS X). Maybe, their code could serve as an
example for how to structure the JIT interface so it can cope with
different ABIs.

Jaos works on top of an abstraction called "object kernel", which
basically is an API to garbage collection, synchronization, etc. Patrik
Reali might be able to tell the list more about this.

>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.

I think it would be very wasteful to compute this information twice, but
it might be very difficult to define common data structures that are
suitable for everyone. Might it be sufficient if a verifier could store
some opaque reference for later use by the JIT?

AegisVM writes that they have developed a modular bytecode verification
architecture, but I didn't look at this yet.

Another thing that might be interesting to share is parts of a compiler
backend, such as assemblers.

-- Sascha

Sascha Brawer, address@hidden, http://www.dandelis.ch/people/brawer/