Re: JIT pluggability

[Chris Gray]

On Friday 09 January 2004 09:45, Sascha Brawer wrote:
> Tom Tromey <address@hidden> wrote on Thu, 8 Jan 2004 17:48:59 -0700:
> >[standard pluggable JIT interface]
>
> This would indeed be quite nice, IMHO.

IMHO2 (that should probably be 3 or 4 by now).

I suspect that the interface to GC will be hard to define, though. There are 
several possible models, including:
  1. The mutator (JITted code) tells GC, "hey! I just mutated something!", 
whereupon GC either (a) aborts the current attempt to mark the heap or (b) 
makes a note to re-mark the affected objects before doing a sweep.
  2. No one is allowed to mutate anything during the marking process, so a 
protocol is devised which ensures this without deadlock.

And that's only counting mark-and-sweep collectors ...

> >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, address@hidden, http://www.dandelis.ch/people/brawer/
>
>
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath

-- 
Chris Gray                                  /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi              http://www.kiffer.be/k/
address@hidden                                      +32 477 599 703