[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JIT pluggability (ABI Issues)

From: Patrik Reali
Subject: Re: JIT pluggability (ABI Issues)
Date: Mon, 12 Jan 2004 21:28:59 +0100

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 Reali

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

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]