harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sh...@computer.org
Subject Re: Against using Java to implement Java
Date Wed, 18 May 2005 07:04:32 GMT
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 <tromey@redhat.com>

> 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	shudo@computer.org	http://www.shudo.net/

Mime
View raw message