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 <[EMAIL PROTECTED]> wrote:
Tom Tromey <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath