Hi All, I wanted to point out some existing work in this area - OpenJIT 2 - being developed at the Tokyo Institute of Technology by Fuyuhiko Maruyama. Here is a link to his research page: http://matsu-www.is.titech.ac.jp/~maruyama/research.html
Fuyuhiko's research is primarily focused on developing VM-independent JIT compilers. To this end, he is experimenting with several VMs including the Aroma VM (a research VM primarily developed by me). So far, I have been a passive observer on the Classpath list. However, I would be interested in contributing to an effort to define such a standard interface. If there is a spinoff group, please let me know. Thanks! Sincerely, Niranjan ---------------------------------------------------------------------- Niranjan Suri [EMAIL PROTECTED] Institute for Human & Machine Cognition 40 S. Alcaniz St. University of West Florida Pensacola, FL 32502 ----- Original Message ----- From: "Tom Tromey" <[EMAIL PROTECTED]> To: "GNU Classpath Project" <[EMAIL PROTECTED]> Sent: Thursday, January 08, 2004 6:48 PM Subject: JIT pluggability > A few of us (at least Dalibor, Grzegorz, Mark, and me) have talked a > bit on irc about other possibilities for collaboration in the free > Java. Classpath has been such a success that it seems logical that we > should start looking for ways to expand our sphere of collaboration. > > One thing we talked about is the possibility of defining a standard > pluggable JIT interface, making it easier to mix-and-match JITs and > interpreters across VMs. > > To that end I wrote up a short bullet list of problem areas, mostly > technical things that the VM would need to somehow export to a > pluggable JIT. > > Tom > > > License. > Does it even make sense to have a license for an API? > What licenses are appropriate for a JIT plugin? > > 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... > > ABI Issues > > - Object layout, including array layout, field offsets, etc > - Method call ABI > - vtable layout > - Interface calls. Some systems have constant-time interface calls. > I suggest we require a simple name lookup, and also provide an > interface to constant-time calls for JITs that can take advantage of > them. > - Exception handling - throwing and catching. > - Name lookup, eg class, method, etc. > - Garbage collector interface. > - Synchronization API > - API for "new" > - Cast checking API > - Array assignment API > - Class initialization API > > > 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. > > - Some kind of negotiation API. The JVM can indicate its > requirements, the JIT can indicate its capabilities. Non-matching > JITs will be ignored by the JVM. > > For instance, gcj is pretty much tied to a conservative GC; if > there were a JIT that couldn't work in this environment it wouldn't > make sense to try to load it into libgcj. > > > Lower Priority > > - Debugging interface > - Optimization interface? > Keeping track of quality of compiler? > Bookkeeping for profiling? > > > _______________________________________________ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath > _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
