Well that's the theory but I think you'll find in practice that real JITs cheat and inline object allocation using their knowledge of the GC internals.
And there is no way that a JIT is going to implement synchronized methods by doing a "monitorEnter" function call! Dave On 5/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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/ >
