Re: JIT pluggability (ABI Issues)

[Patrik Reali]

ABI Issues.

I would divide this in three parts: allocation, calling convention, code 
patterns.

Allocation deals with the addresses of the data structures and is fairly 
easy to deal with. The information needed is:
* size for each basic type
* padding/alignment of each type (in an object, in an array)
* class layout (do we really need this? I guess the fields are allocated in 
the row as they are declared)
* class hidden fields (type descriptor, locks, ...)
* array layout (this may get complicated)
* method number / offset in the vtable or itable
* class numbering / interface numbering (for the systems that use this 
information)
* Strings (some systems may have some special implementations here)

Calling Convention
* left-to-right (as in java) or right-to-left (as in C)
* self (first or last?)
* size and alignment issues
* return values (on register? on stack?)
* which params are passed on stack / in a register
* register saving policies

Code Patterns (using a system call or some inlined code)
* method invocation (i.e. type descriptor layout)
* class allocation
* array allocation
* class initialization
* locking / unlocking
* switch-tables (Jaos has a table with the absolute address of each switch 
destination, this must be patched by the linker)
[... I'm sure I'm missing some here...]


I think allocation is fairly simple to deal with. In fact, each backend 
could provide an implementation class which computes the allocation values.

Calling convention and code pattern configuration may make even the 
simplest compiler become too complex to implement.... please correct me if 
wrong (this is just an assumption).


-Patrik

--------------------------------
Patrik Reali
http://www.reali.ch/~patrik/
http://www.oberon.ethz.ch/jaos/
http://iiop-net.sourceforge.net/



--On Freitag, 9. Januar 2004 09:45 +0100 Sascha Brawer <address@hidden> 
wrote:

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