There is an old document describing a JIT interface though ORP should be more advanced, for example, as having GC interface.
The JIT Compiler Interface Specification http://java.sun.com/docs/jit_interface.html Sun's Classic VM, which was a reference VM, of JDK 1.0.2 and 1.1.X implements this interface and it was modified a bit for J2SDK 1.2. There were actually multiple JIT compilers based on this JIT interface including Symantec JIT, OpenJIT, shuJIT and TYA. This interface is not enough to support advanced optimizations including adaptive compilation, which today's Sun's and IBM's runtimes do. Adaptive compilation needs cooperation by an interpreter (or a baseline compiler) and I am not sure whether it can be factored out from the JVM core. From: Tom Tromey <[EMAIL PROTECTED]> > David> Maybe a concrete example would help. Let's say you have a GC module > David> written in C. One of it's API calls is to allocate a new object. How > David> is your JIT module going to produce code to use that API? Via a C > David> function pointer? > > Yes. > > One way is to mandate link- or compile-time pluggability only. Then > this can be done by name. Your JIT just references > '&harmony_allocate_object' in its source and uses this pointer > in the code it generates. > > The other way is to have the JIT call some central function to get a > pointer to the allocator function (or functions, in libgcj it turned > out to be useful to have several). This only needs to be done once, > at startup. > > > For folks interested in pluggability, I advise downloading a copy of > ORP and reading through it. ORP already solved these problems in a > fairly reasonable way. Kazuyuki Shudo [EMAIL PROTECTED] http://www.shudo.net/
